Subject: Re: [rbridge] WG last call: draft-ietf-trill-rbridge-channel-01.txt

From: Donald Eastlake <[email-masked]>
Date: Tue, 5 Jul 2011 15:41:19 -0400

I've reviewed this draft and think there are two changes that should be made:

(1) The Inner.VLAN label for RBridge Channel messages is currently
specified in Section 2.1.3. For TRILL unicast frames, it says

   "For channel messages sent as a known unicast TRILL Data frames, if
   the message is one-hop it is RECOMMENDED that the Inner.VLAN ID be
   the Designated VLAN on that hop. For multi-hop unicast OAM messages,
   it is RECOMMENDED that the Inner.VLAN ID be the default VLAN 1."

However, this is the Inner.VLAN so it is not clear what the Designated
VLAN has to do with this field. I would suggest that, as the Hop Count
was changed to a default that can be varied by the specification of a
particular channel protocol, the text here should be more like:

   "For channel messages sent as known unicast TRILL Data frames the
   default value for the Inner.VLAN ID is VLAN 1 but particular
   RBridge Channel protocols MAY specify other values."

(2) In Section 5, there are some restrictions on the bit vectors that
can appear but it does not say what you should do if those
restrictions are violated. In particular, it says

   "An RBridge
   Channel protocols supported bit vector MUST NOT extend beyond the end
   of the value in the APPsub-TLV (see Section 6) in which it occurs. If
   multiple byte-aligned bit vectors are present in one such APPsub-TLV,
   they are contiguous, the BVL field for the next starting immediately
   after the last byte of bits for the previous. The one or more bit
   vectors present MUST exactly fill the APPsub-TLV value."

I suggest it should be something like:

   "An RBridge Channel protocols-supported bit vector MUST NOT extend
   beyond the end of the value in the APPsub-TLV (see Section 6) in
   which it occurs. If it does, it is ignored. If multiple
   byte-aligned bit vectors are present in one such APPsub-TLV, they
   are contiguous, the BVL field for the next starting immediately
   after the last byte of bits for the previous. The one or more bit
   vectors present MUST exactly fill the APPsub-TLV value. If there
   are one or two bytes of value left over, they are ignored; if more
   than two, an attempt is made to parse them as one or more bit
   vectors."

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

On Mon, Jun 27, 2011 at 10:49 AM, Erik Nordmark <[email-masked]> wrote:
>
> The working group last call for "RBridges: TRILL RBridge Channel
> Support" <draft-ietf-trill-rbridge-channel-01.txt> runs for two weeks
> from today ending on July 11th.
>
>    Erik
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Jul 2011 08:25:09 -0700

On 6/27/11 7:49 AM, Erik Nordmark wrote:
> Support"<draft-ietf-trill-rbridge-channel-01.txt>  runs for two weeks

<wg co-chair hat off>

In section 2.2 the document talks about the TRILL Header with:
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |V=0| R |M| Ext-Len | Hop Count |

What value do we think we are adding by renaming the op-length field in 
the TRILL base protocol specification to be called ext-len in this 
specification? Seems like that is just adding an opportunity for confusion.

I see references to an "Alert extended header flag", but that term 
doesn't exist in the base or options specifications. Is this also a 
rename of some form?

    Erik

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 18 Jul 2011 00:59:55 -0400

Hi Erik,

> In section 2.2 the document talks about the TRILL Header with:

Well, maybe I went a bit overboard on the change but it was discussed
in Prague to change the options draft to at least use the term
extended header flag for the flag bits provided.

> doesn't exist in the base or options specifications. Is this also a

There has been an Alert flag mentioned in the RBridge Channel draft
for a while, I believe. But it seemed like it would be useful for
other messages as well as RBridge channel messages that needed slow
path processing, so, I posted the message here:
http://www.postel.org/pipermail/rbridge/2011-May/004420.html

In the current http://tools.ietf.org/html/draft-ietf-trill-rbridge-options-05
it seems to be sometimes called the "Alert extended flag" and
sometimes called the "Alert extended header flag"... This should be
made more consistent, in my opinion.

Thanks,
Donald