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

[Radia Perlman]

More re: Ayan Banerjee's comments on protocol-10:


>
>
> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear.
>   

How about adding a comma after "controls"
> Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should
> we remove this optimization (delete last 3 paras) 
>   
I think that the optimization is particularly valuable when IS-IS is 
operating in layer 2. And it
doesn't add complexity, so I see no downside to this.
> Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for
> trill data frames, does this imply that 
>                             vlans are getting tunneled with a different
> outer vlan-id. Just want to make this 
>                             explicit.
>   
Yes. The inner and outer VLAN tags are unrelated on encapsualted frames. 
I thought the
spec was clear about this.
> Item 16: Section 4.2.3.3 - (last note - should this must be the
> ext-ckt-id for P2P, and in a lan. This implies
>                            that we should mandate 3-way handshake for
> P2P links
>   
> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
> all (see note 3 in the last call) 
>
> Item 18: Section 4.3 - Distribution tree (see note 3 in last call and
> please see draft-ward) 
>   

Hmm. I don't understand the above comments, probably because I don't 
know what "note 5"
and "note 3" are referring to.
> Item 19: Section 4.3.1 - Talk about parallel links and what needs to
> break them 
>
> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
> and go everywhere) 
>
>   
Can you be more specific about your concern? I can't tell, based on 
reading the section, what you're
asking about.
> Item 21: Section 4.4.1.2 - Second last paragraph - please change the
> last sentence.
>   

I think the last sentence you are referring to is:

>>(Using a unicast
>>   Outer.MacDA is of no benefit on a point-to-point link but may result
>>   in substantial savings if the link is actually a bridged LAN with
>>   many bridged branches and end stations, to all of which the frame may>>
>>   get flooded if a multicast destination is used.)

Not sure what's wrong with it...


> Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on
> the link (paragraph 2, consider a P2P case).
>                            Or make a statement, that on a P2P, rbridges
> are automatically AFs.
>   
I think this is just a simple clarification. That if it's a P2P case 
RBridge-endnode, that the
RBridge is automatically an AF...
> Item 23: Section 4.5 needs more text on forwarding of various classes of
> multicast control plane packets
>                      some are forwarded using a special address while
> other are flooded.
>   

Hope Donald understands this one...
> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 
>   
It might be nice to quote the offending text, but I think you are 
referring to:

>>   When the appointed forwarder lost counter for RBridge RBn for VLAN-x
>>   is observed to increase via the core TRILL IS-IS link state database
>>   but RBn continues to be an appointed forwarder for VLAN-x on at least
>>   one of its ports, every other RBridge that is an appointed forwarder
>>   for VLAN-x modifies the aging of all the addresses it has learned by
>>   decapsulating native frames in VLAN-x from ingress RBridge RBn as
>>   follows: The time remaining for each entry is adjusted to be no
>>   larger than a per RBridge configuration parameter called (to
>>   correspond to [802.1Q]) "Forward Delay".

Hmm. I don't remember that section, and don't remember the purpose of
counting the number of times appointed forwarder status is lost. Wouldn't
the sequence number on the ESADI (together with the CSNP to assure delivery
of the latest ESADI from each RBridge) make is unnecessary to have a
"appointed forwarder lost counter"?



> Item 25: Section 4.6.3 - Not sure if mis-configuration detection being
> carried in the LSP is a good idea. 
>                          Assuming that it stays there, I do not see any
> text on what to do when things are 
>                          mis-configured. If this is just a log, I would
> suggest that we take this out-of-band
>                          and configuration mismatch issues be handled
> separately. 
>   
Adding optional information into LSPs to detect misconfiguration, and 
not saying what to do as a result
of this information, was a compromise. One could have RBridges act on 
the information, or
have some sort of management tool that looks through things for 
misconfigurations. Seems like a good
idea and mostly harmless.
>
> Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports,
> run STP ? If not, why not? I am 
>                            guessing that statement is talking about
> trunk ports; if so can we make that 
>                            explicit.
>   

The sentence is
 >>"Except for this optional capability,

 >>  RBridges MUST NOT send spanning tree BPDUs."

I don't remember that. Why did we put that in? I might make an independent note about
this...