[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt
Ayan Banerjee (ayabaner)
ayabaner at cisco.com
Wed Nov 26 10:48:40 PST 2008
Please see attached comments to the last call on
Item 1: Section 1.3, can we change the order of control
frame/trill-frame/native-frame (editing nits)
Item 2: Section 2.1 has reference to ESADI as an IS-IS instance. I
believe we said that this is no
longer an IS-IS protocol. Can we please update the draft
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
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
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 18.104.22.168 - 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
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
Item 10: Section 22.214.171.124 - New section -- I think that we are better
served with a P2P IIH section in the draft.
Item 11: Section 126.96.36.199.1 - Are Core IS-IS hellos tagged ? Maybe okay
for LAN, but is this true for P2P
Item 12: Section 188.8.131.52.1 - Last sentence ?? Not sure I follow this,
can this be re-written please.
Item 13: Section 184.108.40.206.2 - Wording of bullet 5 is unclear.
Item 14: Section 220.127.116.11.2 - Based on feedback from the IS-IS WG should
we remove this optimization (delete last 3 paras)
Item 15: section 18.104.22.168 - (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
Item 16: Section 22.214.171.124 - (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
Item 17: Section 126.96.36.199 - (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
Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address
and go everywhere)
Item 21: Section 188.8.131.52 - Second last paragraph - please change the
Item 22: Section 184.108.40.206 - 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
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
Item 27: Section 220.127.116.11 - 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
Item 28: Section A.2 - Solution 4 to problem 1- what optional feature?
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
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