Subject: [rbridge] Resolving comments in Quebec City on draft-ietf-trill-rbridge-options-05

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Sep 2011 21:37:00 -0400

Hi,

I'd like to go ahead and make changes in the TRILL Header Extensions
(aka Options) draft based on my presentation at the most recent TRILL
WG meeting in Quebec City and resolving the comments made at that
meeting. Basically, the deviation from the changes in my presentation,
to resolve the comments made, would be the following:

1) More radical simplification: There were comments that the total set
of mechanisms in the draft seemed too complex and insufficiently
motivated. Suggested resolution is to move the TLV options and ECN to
a separate document to make it easier to advance the remaining
simplified header extension draft.

2) Alert bit: This was described as forcing the frame to the slow
path, a description which constrains implementations unnecessarily.
Furthermore, the motivation is the somewhat narrower case of RBridge
Channel protocols that want hop-by-hop processing. Suggested
resolution is to call it the RBridge Channel Alert bit and just say
that it indicates that the frame is an RBridge Channel protocol frame
that is requesting hop-by-hop processing. It would be left to
implementations whether this involved diverting the frame to the slow
path or something else.

3) Border bits: There were some bits in my presentation, that were
labeled as being related to "border RBridges", that is, hypothetical
multi-level IS-IS RBridges that connected to both Level 1 and Level 2.
But such RBridges have not yet been specified. Suggested resolution is
to just label these bits as "reserved".

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 29 Sep 2011 12:18:37 -0700

Some comments inline.

> simplified header extension draft.

This makes sense.  Having multiple ways of defining options
was adding unnecessary complexity.

> implementations whether this involved diverting the frame to the slow

No strong opinion on this.

> to just label these bits as "reserved".

Makes sense since the functionality is not yet defined.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge