Subject: Re: [rbridge] Critical bits for options

From: [email-masked]
Date: Wed, 12 Dec 2007 11:45:47 +0800

(using a "please limit your internet to 10 minutes" machine at the conference, so hopefully I've not misinterpreted
the email).

Eric -- I very much sympathize with your email. In an earlier version of the spec, Don had a couple of pages
defining options formats, and I thought it was just too complicated, since I didn't think we'd ever use options,
and I've never liked "critical" options.

However, he did tell me some examples of options. We could always not have options, and only allow them with
the next version header, but here are some examples:
a) a "customer ID" that you want transit RBridges to just ignore, but will be useful for ingress and egress RBridges.
b) a way of compressing the data packet, that you should be careful that your upstream guy knows how to do
before you send it, but it's safer to make it critical so in case you accidentally send it to him he won't misparse it
c) cryptographic protection (again, should be critical so someone doesn't try to interpret an encrypted packet).

So he won me over and convinced me that at some point we might want to allow all 4 types of options (critical/not,
EtE, ItE).

Radia

----- Original Message -----
From: Eric Gray <[email-masked]>
Date: Monday, December 10, 2007 11:44 pm
Subject: Re: [rbridge] Critical bits for options

> Radia, Donald, et al,
> 
> 	The one thing I don't seem to be getting out of this
> discussion is even the most general idea what the application
> is (or applications are) for these 'options' we are talking
> about - or even a vague idea when and where they may apply.
> 
> 	I assume - because we're talking about HbH and E2E -
> that we're talking about data frames.  Frankly the idea of
> putting data frames in jeopardy because some implementation
> downstream from the ingress doesn't understand (or chooses to
> pretend not to understand) an option is an EXTREMELY powerful 
> argument for NEVER using options - and certainly not any of
> the 'critical options' that might provide an excuse to drop
> an entire class of frames.  This is - in a very real way -
> roughly the same as providing yet another discard eligibility
> mechanism since any implementation could decide to discard a
> frame containing a 'critical option' - and be justified in
> doing so.  
> 
> 	Also note that - particularly for data frames - the most
> reasonable interpretation for 'discard' is 'silent discard' 
> since returning an error for every dropped frame (or even on a
> periodic basis while dropping frames) is going to be a problem
> - especially if some subset of all implementations 'cleverly'
> decides to increase their 'sensitivity' to 'critical options'
> under congestion conditions (very likely, given that - under
> congestion - it is very likely that implementations will not
> be able to keep up with at least some processing of 'critical
> options').
> 
> 	If that is - in fact - a correct understanding of the 
> intent, then we're wasting time even talking about it (given 
> the unlikelihood of there ever being a use for such a thing).
> So that makes me ask: who dreamed this nightmare up and why?
> 
> 	On the other hand, at least one person seems to interpret
> this 'critical  option' indicator as 'must be processed' - which
> includes 'process on the slow path' if you don't support doing
> so on the fast path.  The distinction - again particularly for
> data frames - is minor, given that it will not take long to 
> over-whelm the slow path with data frames if we start seeing a
> lot of 'critical options' and it will then be the case that the
> implementations not capable of fast path processing of 'critical
> options' will have no choice but to discard them.
> 
> 	However, this latter case makes some sense if there is an
> application for 'critical options' that either never, or very
> rarely - results in using 'critical options' - but only 'some
> sense', given the possibility that we're relying on a behavior
> that probably cannot be reliably/deterministically predicted.
> 
> 	So, my apologies if I am the only one that doesn't know
> the answer to this question - but - what is the point of this
> discussion (i.e. why do we need options and why 'critical' vs.
> 'non-critical' or HbH vs. E2E)?
> 
> 	Based on the discussion so far (and as I have understood
> it), I cannot make an informed decision.  All sorts of issues 
> come to mind in the absence of knowing why we need this...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [[email-masked]] On Behalf Of Radia Perlman
> > Sent: Tuesday, December 04, 2007 10:03 PM
> > To: [email-masked]
> > Subject: [rbridge] Critical bits for options
> > 
> > I'd like to make sure the decision about whether to define 
> > critical bits 
> > for options is made with "informed consent" of the WG. I will write
> > this with no opinion -- just the tradeoffs.
> > 
> > Currently the TRILL spec says to ignore all options -- the only 
> thing 
> > the spec says is how to skip the options, if any.
> > 
> > A "critical" option (some people call it "mandatory") is an 
> > option that 
> > if it appears and you don't understand it, you MUST drop
> > the packet. A noncritical option is one that you are allowed 
> > to ignore 
> > and skip over.
> > 
> > The way the spec is now precludes critical options, because 
> RBridges 
> > following the current spec will skip all options.
> > 
> > An alternative is for TRILL to define two bits at the 
> > beginning of the 
> > options (these bits only appear if the options length is
> > greater than 0).
> > 
> > The two bits are:
> > a) a critical hop-by-hop option exists
> > b) a critical end-to-end option exists.
> > 
> > If we define these bits, then an egress RBridge MUST look to see 
> if 
> > either of those bits are set, and if so, parse the options.
> > A transit RBridge MUST look to see if the hop-by-hop bit is 
> > set, and if 
> > so, MUST parse the hop-by-hop options.
> > Though I suppose an RBridge that doesn't support ANY critical 
> options 
> > would know based on the presence of a critical
> > option that it should drop the packet, without having to 
> > parse to find 
> > the critical option.
> > 
> > So, our choices as a WG:
> > 
> > Choice A: Define NOW that the first 2 bits in the option 
> > portion, if the 
> > option length is nonzero are those two
> > critical bits. And that if you are forwarding an encapsulated 
> data 
> > packet (i.e., you are acting as a transit RBridge
> > for this packet), and thost of choice first (hop-by-hop 
> > critical) bit is 
> > set, you MUST drop the packet. And if you are egress
> > RBridge, and either of the first two bits are set, you MUST 
> > drop the packet.
> > 
> > Choice B: Leave the spec as it is
> > 
> > The cost of choice A is a bit more complexity, and a bit more 
> > overhead 
> > of forwarding because of having the set the bit.
> > The cost of choice B is that we cannot ever define critical options.
> > 
> > The other arguments might be
> > . how likely is it that we'd ever need critical options? Can 
> > we imagine 
> > some examples that we'd ever really want/need?
> > . we could support such things by using a new version TRILL 
> > header when 
> > including critical options, so we are not
> > really precluding critical options.
> > . we could advertise (in LSPs for end-to-end critical 
> > options, in Hellos 
> > for hop-by-hop critical options), support for critical
> > options, and the previous hop RBridge can throw the packet away 
> if 
> > there's no way to forward it without the critical option, so
> > we don't really need for the receiving RBridge to discard the 
> packet.> . how bad would it be for an RBridge to ignore a critical 
> option?> 
> > So...what do people think?
> > 
> > Radia
> > 
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> 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: "Drake, John E" <[email-masked]>
Date: Thu, 13 Dec 2007 10:44:57 -0800

Radia,

The customer ID listed in your e-mail, below, makes no sense to me.  How
would the ingress discover this information and what would the egress do
with it?  

I'm not sure there is any value in compression or encryption, for the
reasons I listed in the reply I just sent Donald, but if compression
and/or encryption were to be performed, wouldn't it be done on all
packets between ingress and egress, and wouldn't there need to be a
negotiation between ingress and egress on the specifics of the
compresssion and/or encryption protocol to be used?

If so, then the options field is totally useless because the ingress and
egress will know exactly how to perform packet processing without it.
It also  means that these types of functions can be implemented without
being specified in any Rbridge spec.

Thanks,

John 

>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, December 11, 2007 7:46 PM
>To: Eric Gray
>Cc: [email-masked]
>(using a "please limit your internet to 10 minutes" machine at 
>the conference, so hopefully I've not misinterpreted the email).
>
>Eric -- I very much sympathize with your email. In an earlier 
>version of the spec, Don had a couple of pages defining 
>options formats, and I thought it was just too complicated, 
>since I didn't think we'd ever use options, and I've never 
>liked "critical" options.
>
>However, he did tell me some examples of options. We could 
>always not have options, and only allow them with the next 
>version header, but here are some examples:
>a) a "customer ID" that you want transit RBridges to just 
>ignore, but will be useful for ingress and egress RBridges.
>b) a way of compressing the data packet, that you should be 
>careful that your upstream guy knows how to do before you send 
>it, but it's safer to make it critical so in case you 
>accidentally send it to him he won't misparse it
>c) cryptographic protection (again, should be critical so 
>someone doesn't try to interpret an encrypted packet).
>
>So he won me over and convinced me that at some point we might 
>want to allow all 4 types of options (critical/not, EtE, ItE).
>
>Radia
>
>discussion is 
>> even the most general idea what the application is (or applications 
>> are) for these 'options' we are talking about - or even a vague idea 
>> when and where they may apply.
>> 
>> 	I assume - because we're talking about HbH and E2E - that we're 
>> talking about data frames.  Frankly the idea of putting data 
>frames in 
>> jeopardy because some implementation downstream from the ingress 
>> doesn't understand (or chooses to pretend not to understand) 
>an option 
>> is an EXTREMELY powerful argument for NEVER using options - and 
>> certainly not any of the 'critical options' that might provide an 
>> excuse to drop an entire class of frames.  This is - in a very real 
>> way - roughly the same as providing yet another discard eligibility 
>> mechanism since any implementation could decide to discard a frame 
>> containing a 'critical option' - and be justified in doing so.
>> 
>> 	Also note that - particularly for data frames - the 
>most reasonable 
>> interpretation for 'discard' is 'silent discard'
>> congestion - it is very likely that implementations will not be able 
>> to keep up with at least some processing of 'critical options').
>> 
>intent, then 
>> we're wasting time even talking about it (given the unlikelihood of 
>> there ever being a use for such a thing).
>> 	On the other hand, at least one person seems to interpret this 
>> 'critical  option' indicator as 'must be processed' - which includes 
>> 'process on the slow path' if you don't support doing so on the fast 
>> path.  The distinction - again particularly for data frames - is 
>> minor, given that it will not take long to over-whelm the slow path 
>> with data frames if we start seeing a lot of 'critical 
>options' and it 
>> will then be the case that the implementations not capable of fast 
>> path processing of 'critical options' will have no choice but to 
>> discard them.
>> 
>> 	However, this latter case makes some sense if there is 
>an application 
>> for 'critical options' that either never, or very rarely - 
>results in 
>> using 'critical options' - but only 'some sense', given the 
>> possibility that we're relying on a behavior that probably cannot be 
>> reliably/deterministically predicted.
>> 
>the answer to 
>> this question - but - what is the point of this discussion (i.e. why 
>> do we need options and why 'critical' vs.
>> 	Based on the discussion so far (and as I have understood it), I 
>> cannot make an informed decision.  All sorts of issues come 
>to mind in 
>> the absence of knowing why we need this...
>> 
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson
>> 
>critical 
>> > bits for options is made with "informed consent" of the WG. I will 
>> > write this with no opinion -- just the tradeoffs.
>> > 
>> > A "critical" option (some people call it "mandatory") is an option 
>> > that if it appears and you don't understand it, you MUST drop the 
>> > packet. A noncritical option is one that you are allowed to ignore 
>> > and skip over.
>> > 
>> > An alternative is for TRILL to define two bits at the beginning of 
>> > the options (these bits only appear if the options length 
>is greater 
>> > than 0).
>> > 
>> > The two bits are:
>> > A transit RBridge MUST look to see if the hop-by-hop bit 
>is set, and 
>> > if so, MUST parse the hop-by-hop options.
>> > would know based on the presence of a critical option that 
>it should 
>> > drop the packet, without having to parse to find the critical 
>> > option.
>> > 
>> > So, our choices as a WG:
>> > 
>portion, if 
>> > the option length is nonzero are those two critical bits. And that 
>> > if you are forwarding an encapsulated
>> data
>> > packet (i.e., you are acting as a transit RBridge for this 
>packet), 
>> > and thost of choice first (hop-by-hop
>> > critical) bit is
>> > set, you MUST drop the packet. And if you are egress RBridge, and 
>> > either of the first two bits are set, you MUST drop the packet.
>> > 
>> > overhead of forwarding because of having the set the bit.
>> > . how likely is it that we'd ever need critical options? Can we 
>> > imagine some examples that we'd ever really want/need?
>> > . we could support such things by using a new version TRILL header 
>> > when including critical options, so we are not really precluding 
>> > critical options.
>> > . we could advertise (in LSPs for end-to-end critical options, in 
>> > Hellos for hop-by-hop critical options), support for critical 
>> > there's no way to forward it without the critical option, so we 
>> > don't really need for the receiving RBridge to discard the

---

From: Radia Perlman <[email-masked]>
Date: Thu, 13 Dec 2007 14:53:15 -0800

John -- I'm answering your question about "customer ID" offlist because 
it's kind of orthogonal to this thread,
which is how to encode the options. I think it was discussed on the list 
awhile ago, and I will want to
discuss it on the list at length at some point, but I don't want to 
distract people now.

So...what was I mumbling about with "customer ID"...

Suppose you have a provider that is gluing together customer Ethernets. 
Each customer is using VLANs, and with
overlapping numbers. VLAN "3" for one customer is not the same as VLAN 3 
at another customer, and your customers
would not want their VLAN 3 traffic sent to the other customer's VLAN 3.

The way I'd like to do this is for there to be kind of "level 1 TRILL" 
and "level 2 TRILL". Within a customer campus, the
VLAN would be the 12 bit thing defined by IEEE 802.1Q. However, an edge 
RBridge, RB1, at the provider (ones that connect to
customer campuses but are participating in the backbone that connects all
the customer campuses) know that there is actually another level of 
hierarchy; "customer ID". The customer ID can take any
form -- it need not look like a VLAN tag. For instance, it could be a 5 
byte number, or it even could
be variable length. I'll use ASCII strings in this email for the 
customer ID.

RB1 (edge provider RBridge) is configured to know that this port goes to 
customer "ACME-CORP", and this other port goes
to "VWX-ENTERPRISES". To edge RBridges, the concatenation of "customer 
ID" and "VLAN" acts as a larger VLAN space. Let's
call that space "C-VLAN", for "concatenated customer ID and VLAN".
So RB1 keeps a learning table for C-VLANs, and otherwise performs just 
like an ingress/egress RBridge in the current TRILL spec.
When RB1 sees a native frame on a port that RB1 is configured to assume 
belongs in
("ACME-CORP", VLAN 3), it looks in its learning table for C-VLAN 
("ACME-CORP", VLAN 3)
to see if it knows which egress RBridge owns the destination. If RB1 has 
learned that the frame should be forwarded across the
backbone to RB2, then RB1 encapsulates towards RB2, but adds the 
critical ItE option "customer ID="ACME-CORP".

Transit RBridges don't care about the customer ID. Only the egress, RB2, 
needs to understand it. If RB2 does not understand it, then
there is the danger RB2 will forward it to a different customer's "VLAN 3".

Now one could argue that RB1 would not send it to RB2 if RB2 didn't 
understand the "customer ID" option, and I have to admit
I am not all that enthralled with "critical" options.

Hope that clarifies somewhat.

Radia