[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
mshand at cisco.com
Wed Nov 26 10:18:29 PST 2008
I have reviewed the draft from the viewpoint of IS-IS, and I have the
following comments. In view of the dependency on IS-IS protocol encoding
AND protocol operation changes, I believe it is important that we get
agreement with the IS-IS WG on those aspects that affect the operation
of the IS-IS protocol before this draft is set in stone.
The points where I believe some discussion between the working groups is
required include, but may not be limited to, the items I have enumerated
1. The problem of IIH space limitations (typically a maximum of < 1500
octets) and potential number of VLAN tags (220.127.116.11.1) is not discussed.
Even if some range based compression is used there is the possibility of
pathological distributions of VLAN ids (e.g. just the odd ones) causing
problems. There needs to be some guidance on what limitations this may
2. The number of IIHs required to be sent when large numbers of VLANs
are in use (18.104.22.168.1) is of some concern. Again there needs to be some
discussion of what impact this may have in terms of limiting the
scaleability of the protocol, and whether such limitations are acceptable.
3. The loop avoidance mechanisms described in 22.214.171.124 needs to be
verified by the IS-IS WG. In addition the last bullet needs some further
explanation as to what aspect "already provided in IS-IS" is being
referenced. IS-IS will normally only elect a single DIS in such
circumstances, but there is no provision for disabling forwarding as is
4. The VLAN mapping detection (126.96.36.199.3) needs to be verified by IS-IS
WG. In particular the mechanism of setting the mapping detected bit in
the next 5 hellos seems dangerous, since such messages could be lost in
the looping which would ensue when mapping was configured. This should
either be latched until reset, or at the very least latched until it is
detected that it has been actioned by the DRB.
5. It is not clear how the existing VLAN mapping detection will
interoperate with the proposed VLAN mapping extensions discussed in
6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID
USUALLY by appending another octet to the 6 octet system ID owned by the
DRB. This suggests that the possibility of some other way is intended.
If so this needs to be described.
7. The second para of 188.8.131.52 (ESADI participation) needs some rational
for the sending of CSNPs by the non-DRB.
8. Section 184.108.40.206 (TRILL IS-IS frames) states "If the frame protocol is
not IS-IS NSAP..." What does this mean?
Erik Nordmark wrote:
> This message begins a working group last call on
> draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the
> document, it will run for three weeks until Wednesday, November 26th.
> There are three issues in connection with this draft that you may wish
> to note:
> 1. A method of doing VLAN mapping was discussed on the working
> group mailing list. This protocol draft is compatible with that method
> which has been written up in
> draft-perlman-trill-rbridge-vlan-mapping-00. This separate draft could
> be considered for adoption as a working group draft and be progressed
> separately or it could be considered as material to add to the
> protocol draft, perhaps as an appendix.
> 2. The protocol draft does incorporate a change in the
> encapsulation of TRILL IS-IS frames (they are no longer encapsulated
> but are always sent to a different multicast address) and a minor
> change in the encapsulation of TRILL ESADI frames (they have a
> different new inner multicast address). There was discussion of this
> on the mailing list but sufficiently little that it was hard to gauge
> working group opinion.
> 3. There was discussion on the mailing list of alternatives for
> distribution tree root selection and announcement but no changes along
> these lines were made in the draft.
> At least items 1 and 3 above are expected to be discussed at the
> working group meeting in Minneapolis. Should those discussions result in
> any changes to the base draft then we will separately last call those
> Erik and Donald
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge