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

[Radia Perlman]

Re Ayan Banerjee's comments on protocol-10:

a) your concern about spraying of hellos. Indeed there was much 
discussion, with viewpoints ranging
from "send Hellos on every VLAN by all RBridges" (which minimizes the 
possibility of two RBridges
not noticing each other because of weird bridge configurations) to "only 
send Hellos on VLAN 1" (simplicity,
least bandwidth). What is in the spec is a compromise which people 
seemed willing to live with. Only
the DRB (once established) sends Hellos on more than one VLAN, and it 
can be configured to
send on a smaller set of VLANs than the set it supports.

Another option which I kind of liked was to have the RBridge attempt to 
become bridge Root. And
become DRB if and only if it succeeds in being tree Root. We might want 
to revisit that. I happened to
be talking to someone (who hasn't been participating in the WG, but 
might be building this) who brought up
that solution as a suggestion instead of spraying with hellos.

b) differently-configured access and trunk ports: I think all the 
scenarios work. It is the DRB that decides
if it is an access port (and therefore prevents any through-traffic by 
either setting the overload bit or not
creating a pseudonode). So it doesn't matter what the other RBs think 
the port is. And if the DRB
thinks it is a trunk port, it will not assign any designated forwarders.
If the DRB thinks it's a "universal port" (both access and transit), and 
some other RBridge believes
it is a trunk port, that other RBridge will not volunteer to be 
designated forwarder. No problem.
If the other RBridge thinks it's an access port, then given that the DRB 
doesn't claim it's an access port,
its decision is overridden, and it does have to forward.

c) no nickname necessary if not ingress, egress, or tree root

We decided this was a good thing in case nicknames became scarce. It 
seems totally harmless. Just RB
doesn't include a TLV for nickname if it doesn't want a nickname.

d) ESADI instances: I couldn't find the place in the spec you point to 
(you said 4.1.2). I don't see a scalability
problem if endnodes for each VLAN are announced in separate 
announcements. I think the notion of
calling it an "IS-IS instance" (my bad terminology) led to lots of 
confusion, ranging from people thinking
that it meant totally separate per-VLAN topologies of the core, to ... 
not sure what else. I think we've
decided not to call it an "instance" anymore, but just to redefine the 
acronym "ESADI" to be "End System
Advertisement Information". One of the reasons to keep the announcements 
in separate packets for
different VLANs is because of VLAN mapping.

The scalability concerns people have raised for this involve sending 
Hellos per VLAN for these ESADI "instances".
But there are no Hellos. There is, however, a CSNP for each VLAN-ESADI.

e) you said:

>>Item 10: Section 4.2.3.5 - New section -- I think that we are better
>>served with a P2P IIH

Just to confirm on the mailing list what I asked at the meeting (since sometimes
"off the top of people's head at a meeting" might be incorrect):

I was worried about sending a P2P IIH and having it misinterpreted. Someone
said that P2P IIHs and multi-access IIHs are different PDU types. Is this correct?
If so, (or if there is some other way of not getting confused by getting one when
you are expecting the other), it seems OK, but we'd have to look through the
P2P IIH and make sure that all the TRILL information we need is there. I suppose
there is no VLAN information needed, pseudonodes, or information about whether it's
a trunk or access port. maybe there really is no TRILL information needed in
a P2P IIH...

f) You said you were confused by this sentence:
>>Note that an RBridge RBn does not defer to the
>>   DRB listed in a Hello, even if that claimed DRB is higher priority,
>>   if the Hello was sent by an RBridge with lower priority than RBn.

I think that's saying that RB1 might hear a Hello from RB2, wherein RB2 announces
that RB2 thinks RB3 is DRB, and that RB1 should not defer to RB2 unless RB3
actually hears Hellos from RB3.
That's kind of interesting -- maybe it should...

I'm sending this in case my email fails, and will try to respond to the rest
of Ayan's comments later.

Radia





> Item 3: Section 2.3.1 - Spraying of hellos, scalability concerns, text
> is unclear Consider the following topology and the following scenarios.
>       
>       |            |              |
>      RB1--------- RB2 ---------- RB3
>       |            |              |
>       |p1          |p2            |p3
>
> The Rbi's are connected on the top to a TRILL cloud consisting of only
> Rbridges (for ease of discussion). They are connected on the bottom to
> CE switches/network via ports p1, p2, and p3. 
>
> Scenario 1: All ports (p1, p2, and p3) are configured to be access ports
> (as defined in Appendix A of the draft). 
> In this case, Rbi's will spray with hellos on all VLANs configured on
> their respective ports. The intent is if a hello is received by other
> Rbi's and an "adjacency" can be formed, then we want to block ports to
> prevent loops. The intent is such a link should not get in the LSP-DB;
> this is inverse of the operation desired with a traditional-isis-hello.
> Only one port remains forwarding and the others are blocked; if so I
> could not figure out from the draft which one is forwarding (is
> system-id etc used as a tie?). Once this is blocked, it remains blocked
> till we "loose" the adjacency again. It is possible that the requirement
> will be to send in the order of 10,000s hellos/per sec per node. This
> solution of spraying poses scalability concerns for the protocol. Also,
> the announcement of the vlan list (however compressed) may not fit
> within the isis-hello-pdu. 
>
> Scenario 2: All ports (p1, p2, and p3) are configured to be trunk ports
> (as defined in Appendix A of the draft). 
> Once again, Rbi's spray hello on all VLANs. In this case, forming of
> adjacencies is desired, in the sense this links gets in the LSP-DB. Once
> a DRB is elected, only the DRB continues spraying with hellos such that
> future nodes can discover and join the designated vlan to send hellos.
> Nodes other than the DIS after the initial spraying will move to sending
> hellos on the designated vlan only. Question: What happens if the DRB
> does not capture all the vlans, for example RB1 became DRB, but has
> vlans 2,3 on p1 and the others p2 and p3, have vlan 2,3,4. Can a new
> RB4, with vlan 4 configured on it enter this Rbridge LAN and create
> issues? Can we have some text to clearly show the desired operation. 
>
> Scenario 3: Some ports are configured to be trunk and some others access
> (could be due to mis-configuration or error in cabling) Not sure what is
> the desired behavior? Are we saying that "adjacency" must not be formed
> with hellos that have the access "AC" bit set, however, must be formed
> with others. If p1 is the only with AC set, then does it "block" or
> "forward" traffic? I believe that the above scenarios needs to be
> addressed in the TRILL base spec. 
>
>
> Item 4: Section 3.7.3 - An RBridge that will not act as an ingress,
> egress, or tree root need not have a nickname.
>         Do we really want this statement in the base spec ? What if it
> does vlan-mapping, etc. Can we just delete
>         this statement from the dradt. 
>
> Item 5: Section 4.1 - please replace on Ethernet links with (on
> multi-access links). I am hoping that we can be 
>         sensitive to running a P2P mode (configured albeit) on Ethernet
> links. 
>
> Item 6: Section 4.1.2 - ESADI is a single instance or multiple instances
> per vlan as currently defined. I 
>         believe that I had raised scalability concerns with ESADI being
> multiple instances.  
>
> Item 7: Section 4.1.3 - There is talk about TRILL-IS-IS Hellos and outer
> encapsulation. [This is to be 
>         removed as per the last call note 2]. 
>
> Item 8: Section 4.2.2 - TRILL-IS-IS frames must be ALL-Rbridges
> multicast address (unicast address how?)
>         Updates to this section are not in sync with 4.1.3 
>
> Item 9: Section 4.2.3.1 - one rbridge is elected DRB for LAN case, but
> in P2P case there should be no 
>         such thing. I believe that the confusion could be due to the
> fact 
>         the base spec talks about TRILL-IS-IS in terms of LAN IIHs,
> however, P2P IIHs (with a config option) 
>         need to be accounted.  We want text in the base protocol spec
> that says that in the event a link 
>         is configured to be P2P, such DRB election is not needed (as per
> base IS-IS protocol). Also, 
>         with P2P mode configuration, there need not be any spraying of
> hellos. 
>
> Item 10: Section 4.2.3.5 - New section -- I think that we are better
> served with a P2P IIH section in the draft. 
>
> Item 11: Section 4.2.3.1.1 - Are Core IS-IS hellos tagged ? Maybe okay
> for LAN, but is this true for P2P 
>
> Item 12: Section 4.2.3.1.1 - Last sentence ?? Not sure I follow this,
> can this be re-written please.
>
> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. 
>
> 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) 
>
> 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.
>
> 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) 
>
> 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) 
>
> Item 21: Section 4.4.1.2 - Second last paragraph - please change the
> last sentence. 
>
> 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.
>
> 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.
>
> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. 
>
> 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. 
>
> Item 26: Section 4.7.1 - Text is confusing since we are talking about
> creating adjacencies, pseudo-node
>                          LSPs etc. Please see item 3 above and text
> needs to make the scenarios outlined
>                          there clearer.
>
> 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.
>
> Item 28: Section A.2 - Solution 4 to problem 1- what optional feature?
>
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Erik Nordmark
> Sent: Friday, November 07, 2008 8:48 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
>
> 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
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>