Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt interim draft

From: "Donald Eastlake" <[email-masked]>
Date: Thu, 8 Jan 2009 23:33:31 -0500

Hi,

An interim protocol draft-ietf-trill-rbridge-protocol-11.txt is being
posted. It has changes which I believe resolve some the of the WG Last
Call comments but not all of them. A -12 draft will be posted later
resolving more those comments.

draft-ietf-trill-rbridge-protocol-11.txt is being uploaded partly so
that IEEE 802.1 will have the latest to look at during their interim
meeting next week. (802.1 has been asked to comment on the draft from
the point of view of its effect on the Ethernet service model.)

Hopefully draft-ietf-trill-rbridge-protocol-11.txt will appear in the
internet-draft directories tomorrow.

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: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Sat, 24 Jan 2009 11:03:18 -0800

Hi All,

I have been a long time lurker and behind-the-scenes
contributor/reviewer of these TRILL documents. I really enjoyed the
conversations & discussions both online & offline in the group and I
have immensely enjoyed them.

I have a few comments on the Version 11 of the draft. I have broadly
classified them as typos/editorial issues and other issues.

Thanks,
Hari

Typos & Editorial Issues:
##############################

1. Section 4.2.3.1.2 (Page 32)
 
       Do the last three paragraphs in this section really belong to the
section which describes "TRILL IS-IS Hello Contents"? 

2. Section 4.2.3.3
      Under Loop avoidance, second Para, first line: "descrived" should
be "described".

3. Section 4.4.2.3.1 (Page 45)
       First para of this section, fifth line: "know" should be "known".

4. Section 4.7.1 (Page 50)
        In the last para of Page 50, could not the sentence  starting
with "If the DRB asserts...." been better phrased? May be there is an
"and" missing between "Rbridge access link" and "all Rbridge ports..."

5. Section 4.7.3.2 (Page 53)
          The first line in this section: "....seen out a port .." ,
should it not be "....seen at a port..."

6. General Comment:
        The draft references to other companion TRILL specs. Such
sections include Section 3.5, Section 4.2.3.1.3 etc. It would have been
nice to provide a reference to those specs in these places.

Other Comments:
##################

7. Section 3.7 (Page 22)
      How should a Rbridge handle a packet which has the "reserved for
future" and "permanently reserved" Rbridge nicknames in either the
Ingress or Egress Rbridge Nickname fields?

8. Section 3.7.3 (Page 23):
       Here the spec says that a Rbridge that will not act as ingress,
egress or tree root need not have a nickname. I think it is prudent to
mandate that all Rbridges must have a nickname. When certain Rbridges do
not have a nickname, I am concerned that any future debugging/diagnostic
tools may not work well. Is there some real benefits as for a Rbridge
not to have a nickname?

9. Section 4.2.3.3 (Page 33)
        Is root bridge change the only possible event which indicate a
potential topology change in bridged networks?

10. Section 4.3.4 (Page 41)
      The spec says that the TRILL ESADI frames should be treated
similar to non-IP-derived multicast addresses and be pruned on basis of
Inner.VLAN_ID. Could not the TRILL ESADI frames be further pruned by a
Rbridge on the basis of the state it could have built by
listening/snooping on ESADI CSNPs etc? ie if a Rbridge knew that there
are no other ESADI capable Rbridges for a given vlan behind its link,
could it not choose to prune the ESADI packets on that link for that
vlan?

11. Section 4.4.2.3.1 (Page 45)
       Is there a reason why a Rbridge should not prune, if it so
chooses, a known unicast packet based on Inner.VLAN?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: Thursday, January 08, 2009 8:34 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt 
> interim draft
> 
> Hi,
> 
> An interim protocol draft-ietf-trill-rbridge-protocol-11.txt 
> is being posted. It has changes which I believe resolve some 
> the of the WG Last Call comments but not all of them. A -12 
> draft will be posted later resolving more those comments.
> 
> draft-ietf-trill-rbridge-protocol-11.txt is being uploaded 
> partly so that IEEE 802.1 will have the latest to look at 
> during their interim meeting next week. (802.1 has been asked 
> to comment on the draft from the point of view of its effect 
> on the Ethernet service model.)
> 
> Hopefully draft-ietf-trill-rbridge-protocol-11.txt will 
> appear in the internet-draft directories tomorrow.
> 
> Thanks,
> Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 25 Jan 2009 23:30:36 -0500

Hi,

See responses below...

> Typos & Editorial Issues:

Could be a separate section but does relate to Hello contents.

>      Under Loop avoidance, second Para, first line: "descrived" should

Thanks.

>       First para of this section, fifth line: "know" should be "known".

OK.

> "and" missing between "Rbridge access link" and "all Rbridge ports..."

Indeed, there should be an "and" there.

> should it not be "....seen at a port..."

Can't see that much difference. Perhaps more wordy but clearer would
be to say "....seen in the BPDUs received at a port...".

> nice to provide a reference to those specs in these places.

I have no problem with that for things that are further along in the
process than the protocol spec and probably other working group drafts
that are behind the spec but it seems a bit of a stretch if its just a
personal draft at this point...

> Other Comments:

They should be discarded if the egress nickname is one of these
special values as that means an RBridge would not be able to tell how
to forward the frame. It seems like the same should be true if the
ingress RBridge is a special value ingress nickname as that at least
makes it impossible to perform a Reverse Path Forwarding Check. Unless
someone objections, some text will be added saying this.

> tools may not work well. Is there some real benefits as for a Rbridge

Since the System ID seems more stable than the nickname, I would think
that debugging/diagnostic tools should use that.

> potential topology change in bridged networks?

No, but it is the only topology change event that RBridges need to
worry about. Think of it like this: Assume a bridged LAN connected to
some RBridges. There are several different cases.
     If some links inside the bridge LAN go up/down and/or there is
some reconfiguration of spanning tree, but connectivity as observed
from outside the bridged LAN stays the same, why should connected
RBridges care?
     If one or more bridges or links die in the bridged LAN, some end
stations or RBridges may lose connectivity to the bridged LAN or the
bridged LAN might partition into two or more pieces. This may orphan
some end stations or temporarily interrupt service to some end
stations or even cause the campus to partition, but all this seems
safe.
    But, if links or bridges come up merging two bridged LAN, you
could have two or more appointed forwarders for the same VLAN at the
same time connected to the bridged LAN. This is, in general,
disastrous, resulting in network meltdown. Note that this includes the
case where one of the merged "bridged LANs" is a single bridge.

> could it not choose to prune the ESADI packets on that link for that

RBridges are required to report their ESADI participation in their
LSP. So more pruning complexity for this case could be added. But, to
minimize the burden on transit RBridges, it has not so far.

> chooses, a known unicast packet based on Inner.VLAN?

Pruning only applies to distribution trees. Known unicast frames are
just forwarded hop-by-hop to their egress RBridge. There is no tree to
prune.

Thanks,
Donald