Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-01.txt

From: Donald Eastlake <[email-masked]>
Date: Mon, 2 Jan 2012 22:31:44 -0500

Hi Yizhou,

On Mon, Dec 26, 2011 at 7:26 AM, Yizhou Li <[email-masked]> wrote:
> Hi Donald,
>
> Some comments and thoughts when I read the draft,
>
> 1. pg4, right below bullets
>   "Any RBridge receiving a frame with a critical hop-by-hop extension
>   that it does not implement MUST discard the frame because it is
>   unsafe to process the frame without understanding such a critical
>   extension. Any egress RBridge receiving a frame with a critical
>   ingress-to-egress or hop-by-hop extension it does not implement MUST
>   drop the frame if it is a known unicast frame; if it is a multi-
>   destination TRILL Data frame, then it MUST NOT be egressed at that
>   RBridge but it is still forwarded on the distribution tree. Non-
>   critical extensions can be safely ignored."
>
> It is unclear to me what a RB should do if it receives a multi-destination
> frame with a critical hop-by-hop extension that it does not implement?
> 1st sentence suggests to discard it and the end of second last sentence
> suggests to forward it on the tree?
> Suggest to remove "or hop-by-hop" in 2nd sentence.

Good point. I will remove "or hop-by-hop" and probably split the
paragraph in to three paragraphs, one on hop-by-hop critical, one on
ingress-egress critical, and one on non-critical.

> 2. pg5, L3, "some such frames them to be" -> some of them to be

OK.

> 3. pg7, section 2.3.1,
> Can we call "extensions after the first word in the extensions area" to be
> "TLV extensions"?

I would prefer to leave the wording as is. In the
draft-ietf-trill-rbridge-options working group draft, there is already
one additional word of non-TLV extension described...

> Another general comment, use a table to show the whole extension area
> structure which contains the Extension Header Flags as that in section 2.3
> and the optional non-flag TLV extensions which is 32-bit aligned.

I could extend that digram and adjust the wording a bit so it is
clearer how the word of flags fits in the TRILL Header extension
area... Something like this:

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension     |
|     including TLV extensions ...

> 4. pg4, bottom, Note section.
> I think there is mixture of slow path & fast path case if future hardware
> can support certain flag directly, e.g. some flag requires forwarding the
> frame in data plane as normal and copy it to the control plane for further
> processing at the same time.

While that could happen for some assortments of options and hardware
support, this note is just a general warning to be cautious in using
extensions. I don't think it needs to be more complicated.

> 5. pg10, section 3. Table 1. Extended Header Flags Area
> Suggest to define bit 3 for a critical hop-by-hop RBridge Channel Alert
> Flag. It may be useful in assisting some channel features, like the source
> routing with strict path specified.

I think including such a flag a good idea. I'll add it unless there
are objections, probably as bit 7 so it is adjacent to the
non-critical Channel Alert Flag currently defined in the draft.

> 6. pg8, section 2.4
> Better to explicitly state that the conflicts may not be resolved to achieve
> the same consequence at every transit RB for a single data frame even
> following the rules described. It highly depends on the capability that an
> RB can support.

OK.

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

> Thanks,
> Yizhou
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Donald Eastlake
> Sent: Friday, December 23, 2011 1:18 AM
> To: [email-masked]
> Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-01.txt
>
> This revision just has editorial changes and author information update.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
> On Thu, Dec 22, 2011 at 12:08 PM,  <[email-masked]> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Transparent Interconnection of
> Lots of Links Working Group of the IETF.
>>
>>        Title           : TRILL: Header Extension
>>        Author(s)       : Donald Eastlake
>>                          Anoop Ghanwani
>>                          Vishwas Manral
>>                          Caitlin Bestler
>>        Filename        : draft-ietf-trill-rbridge-extension-01.txt
>>        Pages           : 16
>>        Date            : 2011-12-22
>>
>>   The TRILL base protocol standard specifies minimal hooks to safely
>>   support TRILL Header extensions. This document specifies an initial
>>   extension providing additional flag bits and specifies one of those
>>   bits.
>>
>>
>>
>> A URL for this Internet-Draft is:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-01.tx
> t
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-01.txt
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

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