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

From: Sam Aldrin <[email-masked]>
Date: Wed, 15 Feb 2012 15:02:06 -0800

Dear authors of the draft,

I have read thought the latest version of the draft. I feel this is very useful extension to the header and I support this publication.

I do have few questions, which I hope could be addressed easily. Apologize if they got answered already during earlier versions of the draft. You could safely drop the questions, in the true spirit of this draft :D

1. I understand from the draft wording that, if the rbridge do not support all of the critical header flag extensions, the frame should be dropped. What exactly is the definition of support. Does that mean, it do cannot parse the header extension OR it can understand the flag but chose not to implement? For example, if a frame is sent with critical ingress to egress extension, then only RBridges which support the extension can egress that. Wouldn't that create backward compatibility problem, as frames get dropped?
2. What if the rbridge could interpret these critical flags but chose to not implement? Should it drop the frames as well?
3. Keeping my OAM hat on, how would I know a rbridge do or do not support critical options? Instead of mandating the frame be dropped, if the frame is OAM frame, it should get punted for local processing. That way, an appropriate code could be sent back in the response for the OAM frame.

Cheers
Sam

Sent from my iPad

On Jan 9, 2012, at 8:18 PM, Donald Eastlake <[email-masked]> wrote:

> This version incorporates change discussed on the WG mailing list.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
> 
> 
> On Mon, Jan 9, 2012 at 8:20 AM,  <[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
>>                          Yizhou Li
>>                          Caitlin Bestler
>>        Filename        : draft-ietf-trill-rbridge-extension-02.txt
>>        Pages           : 16
>>        Date            : 2012-01-09
>> 
>>   The IETF TRILL (Transparent Interconnection of Lots of Links) base
>>   protocol specifies minimal hooks to safely support TRILL Header
>>   extensions. This document specifies an initial extension providing
>>   additional flag bits and specifies two of those bits.
>> 
>> 
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-02.txt
>> 
>> 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-02.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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Feb 2012 12:50:26 -0500

Hi Sam,

> I have read thought the latest version of the draft. I feel this is
> very useful extension to the header and I support this publication.

Thanks.

> I do have few questions, which I hope could be addressed
> easily. Apologize if they got answered already during earlier
> versions of the draft. You could safely drop the questions, in the
> true spirit of this draft :D

Well, I like to try to answer all the comments if I can...

> 1. I understand from the draft wording that, if the rbridge does not
> support all of the critical header flag extensions, the frame should
> be dropped.

The RBridge only needs to support the applicable critical header
flags. A transit RBridge doesn't care what ingress-to-egress flags are
set.

>              What exactly is the definition of support. Does that
> mean, if you cannot parse the header extension OR it can understand
> the flag but chose not to implement?

Support is whatever the extension says you need to do to support it.
If it's critical and you can't do what the extension says you need to
do to support it, by the definition of critical, you can't continue
processing without bad things happening, like violations of security
policy, misdeliverly and/or garbling of data, etc. For example
(although this sounds like a bad idea and I'm not suggesting it), you
could have a flag that says the frame payload was gzipped at the
ingress and has to be ungzipped before delivery. Ignorning this and
just delivering the gzipped payload to an unsuspeting end station
would probably not work out so well :-)

I don't know what you mean by "understand the flag but choose not to
implemnt". Being able to tell how long some structure is, for example,
and skipping over it is not "understanding" in a useful sense. If the
structure is non-critical, then by the definition of non-critical,
skipping over it and not doing anything with it is safe. If the
structure is critical, then by the definition of critical, skipping
over it and not doing anything with it but continuing to process the
frame is unsafe and bad things are likely to happen.

>                                       For example, if a frame is sent
> with critical ingress to egress extension, then only RBridges which
> support the extension can egress that. Wouldn't that create backward
> compatibility problem, as frames get dropped?

You can't have it both ways. Either you can never extend the protocol
in a way which is critical or you have to accept the possibility of
encountering a legacy device that will be unable to process the
message. At least here there are ways to find out if some extension is
supported (see below) and ways for the legacy device to know it is
getting something it can't process.

> 2. What if the rbridge could interpret these critical flags but
> chose to not implement? Should it drop the frames as well?

If you could safely ignore something, then it would be non-critical.
If something is critical and you ignore it (either because you didn't
implement it, or you implemented it but choose not to enable that
code, or whatever), then, by the definition of "critical", continuing
to process the frame is unsafe. According to this draft, the frame is
dropped, but a later draft could update this to provide for an error
response as mentioned below.

> 3. Keeping my OAM hat on, how would I know an rbridge does or does
> not support critical options?

This draft just specifies extended header flags, not all possible
types of extensions that could be specified in the future. But for
extended header flags, as the draft says, RBridges advertise the
extended header flags they support in IS-IS PDUs. To be specific, see
draft-eastlake-isis-rfc6326bis, which is referenced in the draft, in
Sections 2.3.1 and 2.2.4 of the 6326bis draft.

>                            Instead of mandating the frame be dropped,
> if the frame is OAM frame, it should get punted for local
> processing. That way, an appropriate code could be sent back in the
> response for the OAM frame.

Good advice for OAM messages which is why such a mechanism is in
draft-ietf-trill-rbridge-channel, also in WGLC, and why there is a
mechanism of that general type in draft-ietf-trill-rbridge-oam. But
since the rbridge-oam draft is not in WGLC right now, I believe the
right thing is for the rbridge-extension draft to say "dropped" and
if/when some later draft specifies an appropriate error response
message at this level, that later draft can say that it updates this
extension draft/RFC.

Thanks,
Donald

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 16 Feb 2012 17:26:11 -0800

Hi Donald,

Thank you for the detailed reply. Please find my comments inline with %sam.

Cheers
Sam

Sent from my iPad

> frame is unsafe and bad things are likely to happen.
%sounds good. I do hope the flags defined will be really critical. Reason I had this question in the first place was, if the flags are so critical in functioning of TRILL, it would have had been defined already. It wouldn't be in the extended flags fields. If the RBridge advertises it cannot support but still part of the network and function, then the flags are not critical after all. I could be way off, but, that was my line of thinking, when I asked first.
> response as mentioned below.
%sam - I do agree if the flag is really critical that further processing of the frame is detrimental to the functioning of Rbridge, it should be dropped. 
> Sections 2.3.1 and 2.2.4 of the 6326bis draft.
%sam - ah! Thanks for pointing it out. I didn't realize that rbridge has to keep track of rbridge capabilities, prior to setting the  extender header flag in the frame. 
> message at this level, that later draft can say that it updates this
%sam - ok, thanks.

---

From: Jon Hudson <[email-masked]>
Date: Sat, 18 Feb 2012 00:25:47 -0800

I have read this and support the document.

Very sorry for missing the 15th deadline, I have been ofline.

On Mon, Jan 9, 2012 at 8:18 PM, Donald Eastlake <[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.
> >

---

From: Mike McBride <[email-masked]>
Date: Mon, 20 Feb 2012 18:59:09 -0800

Likewise. I support the document.

mike

On Sat, Feb 18, 2012 at 12:25 AM, Jon Hudson <[email-masked]> wrote:
>> > directories. This draft is a work item of the Transparent Interconnection of
>> > Lots of Links Working Group of the IETF.
>> >

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 Feb 2012 18:30:01 +0000

Support. 

Linda Dunbar