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

From: "Donald Eastlake" <[email-masked]>
Date: Sun, 4 Jan 2009 22:01:33 -0500

Hi Ayan,

On Wed, Nov 26, 2008 at 1:48 PM, Ayan Banerjee (ayabaner)
<[email-masked]> wrote:
> ...
>
> Item 1: Section 1.3, can we change the order of control
> frame/trill-frame/native-frame (editing nits)

I don't think anyone else reponded to this. Of the five other
possible orders, which would you like? I put control frames first
because their definition is completely self contained. On the other hand
the definitions of TRILL and native frames have some cross referencing
and both currently refer to control frames. Of course, there are other ways
to re-word this...

> ...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Donald Eastlake" <[email-masked]>
Date: Sun, 4 Jan 2009 22:00:33 -0500

Hi Ayan,

See a couple of comments below:

On Fri, Nov 28, 2008 at 5:58 PM, Radia Perlman <[email-masked]> wrote:
> Re Ayan Banerjee's comments on protocol-10:
>
> ...
>
> 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?

Yes.

> 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 think that "Note" should be deleted

> Radia

Thanks,
Donald

---

From: "Donald Eastlake" <[email-masked]>
Date: Sun, 4 Jan 2009 21:56:16 -0500

Hi Ayan,

See below

On Fri, Nov 28, 2008 at 6:26 PM, Radia Perlman <[email-masked]> wrote:
> 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"

How about just simplifying it so it reads:

"5. A flag which, if set, indicates that the sender's port was
configured as an access port. When it is asserted in Hellos
sent by the DRB, all ports on that link act as access ports."

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

I think the last point (note) can be deleted.

>> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose
>> all (see note 3 in the last call)

I guess the comments above and below concern the changes in
distribution tree determination, etc. See other messages.

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

I believe the second paragraph of 4.3.1 does that.

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

? Maybe the word "encapsulated" should be inserted so it says "... then
the encapsulaed frame is forwarded ...".

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

Actually I think the sentence referred to is "Also, RB1 MUST select a
tree that RB1 has
announced (in RB1's own LSP) to be one of those that RB1 may choose as
a distribution tree or the tree with the highest priority root if none
is announced." which is part of the changes for distrbution tree
determination, etc

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

I'll see what I can do. I think it also need to be a bit clearer about
the effect of whether or not the RBridge is an appointed forwarder.

>> 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"?

The sentence does seem a bit long :-)

The provision here has nothing to do with ESADI. The problem is that
for remote end station MAC addresses learned from data, RBridges only
know what the remote RBridge is, not the remote port.

So, assume everything is in the same VLAN X and RBridge A learns some
MAC address is attached to RBridge B. If, at some later point, RBridge
B advertises that it is no longer connected to VLAN X, RBridge A can
forget all those addresses as the path to them is no longer through
RBridge B. This is better than bridges do with a topology change,
which is just trim the time for MAC address cache entries to the
Forwarding Delay.

But what if RBridge B has multiple ports where it is appointed
forwarder for VLAN X and it loses appointed forwarder status for some
but not all of these ports? Some, but not all, of the remote MAC
addresses that RBridge A learned as being accessed bia RBridge B are
probably invalidated. So RBridge A doesn't want to forget all the MAC
addresses it learned from RBridge B. Under these circumstances, it
seems like the best you can do is what a bridge would do for a
topology change, which is trim MAC timers to the Forwarding Delay.

Thanks,
Donald

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 13 Jan 2009 14:10:32 -0800

Donald,

I believe that the itemized list looks fine and I prefer that order. I was
just pointing out that the test in the document before the itemized list has
a different order than the itemized list order. To be specific please modify

   In this document, Layer 2 frames are divided into three categories,
   TRILL frames, control frames, and native frames, as follows:

With 

   In this document, Layer 2 frames are divided into three categories,
   control frames, TRILL frames, and native frames, as follows:

As I had mentioned, just an editing nit.

Thanks,
Ayan

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jan 2009 14:32:36 -0800

Just a clarification:

	TRILL control or 802 control?

Joe

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 13 Jan 2009 14:56:49 -0800

Radia and Donald,

Apologies for the delayed response. I have aggregated information from the
other emails and have clubbed it here.

Clarification for EASDI:
If my understanding of the draft is accurate, there are possibly 4K
vlan-ESADIs and on each node and we are "only" running the CSNP
functionality (of traditional IS-IS). The "hello" functionality is not run
on them. Consider a router that is interested in all "vlans"; such a router
will have to support *all* VLAN-ESADIs. I believe that this is a significant
load on the router. I believe that we should have an optional single-ESADI
instance as well; this will allow for control-plane learning of unicast MAC
addresses in a more scalable fashion. I am fine with having the optional 4K
instances also co-exist; but my preference is to have a single instance for
unicast MAC distribution.

P2P IIHs and LAN IIHs:
When TRILL-IS-IS sends out hellos it does so based on the link capability.
On P2P links (configured or real ones) it sends P2P IIHs and on multi-access
links it sends LAN IIHs. I presume that in TRILL we want to default sending
out LAN IIHs (is this accurate?). We should have a section on P2P IIHs and
just talk about if any functionality/sub-tlvs are not required for that case
(for example, do we need to find a common vlan in P2P like in a LAN -
probably not etc). Note that a P2P IIH and LAN IIH will not be bring up and
adjacency. 

Parallel links between rbridges:
We need information in the draft that states that we break ties using (a)
extended circuit id on P2P links (makes 3-way handshake mandatory) and (b)
in a LAN, use lan circuit id.

Thanks,
Ayan

P.S. I have not fully cross-checked with version 11 to see all that has gone
in, but I will take a look. Also, I will take a closer look on the
hello-AF/AC issue with mis-configurations and get back to you.

On 11/28/08 2:58 PM, "Radia Perlman" <[email-masked]> wrote:

> 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:
> 
> 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. 
>> 
>> 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 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.
>> 
>> P2P links.
>> 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: [email-masked] [mailto:[email-masked]] 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

---

From: "Donald Eastlake" <[email-masked]>
Date: Tue, 13 Jan 2009 18:15:49 -0500

Hi,

See below

On Tue, Jan 13, 2009 at 5:32 PM, Joe Touch <[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Just a clarification:
>

They are, in fact, 802 control frames. But the section being referred
to is defining what the unqualified term "control frame" means in this
document.

> >    control frames, TRILL frames, and native frames, as follows:

OK, I hadn't quite understood your comment. I'll make the change you suggest.

Thanks,
Donald

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkltFoQACgkQE5f5cImnZrt0FACfVLzeqxlEiZQPG6aiNrGq/xam
> x8UAoOtGQYSLpMXUSSvvr/wYoVz+aFbj
> =SdJO
> -----END PGP SIGNATURE-----

--