Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames

From: Radia Perlman <[email-masked]>
Date: Fri, 27 Feb 2009 13:31:23 -0800

This is what I think we should do:

a) unless really broken, we should leave the effect of the current spec, 
so that if someone has implemented it, we
don't change their implementation

b) so, that would imply that on Ethernet, encoding would be as the spec 
says (data and ESADI is
TRILL-encapsulated, TRILL-IS-IS is not TRILL-encapsulated, but has a 
distinct (outer) destination MAC address.

c) if it is considered safer somehow, we could use a bit in the TRILL 
header that is currently set to 0
and define it as the "control" bit, saying that implementations must set 
it to 0 (as they would anyway
according to the current spec) and SHOULD check to make sure it's 0 on 
receipt. But I don't think
we really need that bit.

d) we need to define how to encode TRILL on PPP. As Jim Carlson pointed 
out, the current spec
is at best incomplete, and at worst, incorrect about PPP. One way we 
could fix this is to make sure
we clarify, when things are Ethernet specific, that we are talking only 
about Ethernet links. An example
is when we say you can tell the difference between TRILL IS-IS and TRILL 
data based on the destination
MAC address. It should say "on Ethernet links". And perhaps another 
sentence like "on other types
of links, such as PPP, some other mechanism must exist to differentiate".

e) proposal for PPP is two protocol types, one for TRILL encapsulated 
data and ESADI frames (both
of which would have a TRILL header), and one for "other", where we'd 
say, for instance, that the
first 2 bytes after the PPP header would be a "TRILL protocol type", so 
that we could then encode
more types of "other" than just IS-IS, if we ever need to.

f) we should have a separate document "how to encode TRILL over PPP.

g) I was thinking about how to tunnel TRILL over IP. For that, 
undoubtedly we'd
put in a UDP header. Perhaps it would be useful to define TRILL over IP 
at some point, again
it would be in a separate document.

So....are people OK with this?

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

---

From: James Carlson <[email-masked]>
Date: Fri, 27 Feb 2009 17:50:04 -0500

> of links, such as PPP, some other mechanism must exist to differentiate".

I don't like to have "Foo over X" documents that specify how you must
deviate from the base spec for "Foo" in order to implement, so I think
that sort of a clarification in the base spec is required.  The
mapping described in the base specification (for good or ill) is
Ethernet-only, but it doesn't actually say that.

I also _strongly_ recommend that:

  a.) the ASCII graphic diagrams of the various packet formats be
      included in the base specification to make the encoding clear;
      it's not clear now.

  b.) we say something about the MTU weirdness that this solution
      imposes, and we make the expectations for MTU handling
      completely clear, as it's an interoperability issue.

> f) we should have a separate document "how to encode TRILL over PPP.

I can volunteer to write that one.

> So....are people OK with this?

I think it's a poor solution for a number of reasons (what does
"filter for TRILL" look like?), and this was broken only "recently"
(the old mapping was in the -09 draft, and was changed in -10, well
after we had started implementing and testing), so it should have been
something fixable.

But since it seems we cannot get consensus without keeping this late
and incompatible change to the spec, and I certainly value consensus,
I'll concede.  I hope it doesn't come back to bite.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Jim Burrows <[email-masked]>
Date: Sat, 28 Feb 2009 17:31:40 -0500

I'll have to agree with Jim Carlson with regard to the notion of "Foo  
over X" documents and specs whose scope intermingles one specific  
protocol from one level into a specification at another level. I'm new  
here, and I don't know how far folks may have gotten in implementing  
the draft 10 spec, vs the 09 or the 11, but it also feels wrong to  
stick with a problem that crept into a latish but not final draft of  
the spec fore backward compatibility reasons. I've had to live with  
the sort of problems that this introduces too often.

Is it really too late to fix this?

JimB.

On Feb 27, 2009, at 5:50 PM, James Carlson wrote:

> James Carlson, Solaris Networking              <[email-masked] 
> >