From: "David Addison" <addy@hplb.hpl.hp.com>
Date: Tue, 5 Mar 1996 14:28:17 +0000
To: p8021@nic.hep.net
Subject: Comments on IEEE P802.1p/D2

Here are some comments on the IEEE P802.1p/D2 document;

2.6.6
I am confused by these port modes.
Assume a bridge has multiple ports, with one in mode 1 (BFS) and one in
mode 2 (BFS+EFS). When the FD has no entry for a given multicast
destination address, frames to that address are sent out on both
ports. However, what happens when that address is added to the FD via
the GARP protocol - do frames to that MAC address stop being
forwarded onto the BFS port ?

3.7.2 & Figure 3-7
This description of the switch operation, doesn't seem to indicate
filtering based on source port that happens due to static filtering
entries (3.9.1)

3.7.6
Points a) and c) seem to be the same. Did c) mean to state
M_UNITDATA.indication rather than M_UNITDATA.request ?

9.2b
'Propagation of the the information is achieved by a Proxy Registrar
associated with each port'. Shouldn't this read 'Proxy Applicant' ?

9.4 (a), (b)
If we were to use the Spanning Tree LSAP assignment for
GARP BPDUs, 'old' bridges will not forward the frames, because the
IEEE 802.1D-1990 standard states in 3.12.3 'A Bridge Protocol Entity
that receives a BPDU with an unknown Protocol Identifier shall discard
that BPDU.'
Even if the bridge only performed this action on frames addressed to
the 'Bridge Group Address', we can not use one of the other 15
reserved addresses because IEEE 802.1D-1990 states in 3.12.6 'Frames
containing any of the group addresses specified in Table 3-4 in their
destination address field shall not be relayed by the Bridge.'

9.4 (f)
What does it mean for a port in the BFS mode to support GARP ?
Does it run the Registrar and Applicant state machines for that port ?
Does it silently consume GARP BPDUs ? Does it transmit GARP BPDUs ?

9.5.1.1b
On initial membership registration by the Applicant what is the
default value for JoinTime ? (i.e. before it has been updated by
information from the Bridge in Leave/LeaveAll BPDUs).

Figure 9-4
The arc for ReqLeave from IN->OUT says 'stop jt' as an action. The jt
timer is not running in the IN state.

Table 9-2 Page 37
In the VERY-ANXIOUS state the rJoin event does not correspond to the
state diagram (Fig 9-4). The rJoin event should cause a state
transition to LESS-ANXIOUS (as shown in the state diagram). (It may
also need to restart the jt timer with value T ?)

9.7.1.1.2
It is not clear here if we should always update the JoinTime
variable. Later in section 9.7.1.2.4 it says we only update it, if the
received value is less than the current one.

9.7.1.3.1
The word 'Recipient' is used in this paragraph several times, it should
be replaced with 'Applicant', when referring to the state machine.

9.7.1.3.2 (b)
The word 'Priority' should be replaced with 'Delay'.

9.7.2.3.1 (b)
The word 'Priority' should be replaced with 'Delay'.

9.7.3.3.1
The word 'Recipient' is used instead of 'Applicant'.
Also, when we send a leaveAll BPDU, it states that this should cause a
rLeave event to occur in all the Proxy Applicant state machines on
that port. This should also cause a rLeave event to occur in all the
Registrar state machines on that port, as specified in 9.7.2.2.3.

9.8.3.3
Why is the LeaveAll Type value defined as 3 ? So far we have only used
values, 0 (Join), and 1 (Leave). Is the value 2 reserved ?


Yours,
David.
--
David Addison                   Hewlett-Packard Laboratories, NTD
addy@hplb.hpl.hp.com            Filton Road, Stoke Gifford, Bristol, BS12 6QZ
Tel: +44 (0)117 922 9543        Fax: +44 (0)117 9228924