[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

[mike shand]

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 
below.

1. The problem of IIH space limitations (typically a maximum of < 1500 
octets) and potential number of VLAN tags (4.2.3.1.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 
impose etc.

2. The number of IIHs required to be sent when large numbers of VLANs 
are in use (4.2.3.1.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 4.2.3.3 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 
implied here.

4. The VLAN mapping detection (4.2.3.1.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 
Minneapolis.

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 4.2.4.1 (ESADI participation) needs some rational 
for the sending of CSNPs by the non-DRB.

8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is 
not IS-IS NSAP..." What does this mean?


Mike


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 
> changes.
>
> Erik and Donald
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>