Subject: Re: [rbridge] Ambiguity with IS-IS messages on PPP

From: Caitlin Bestler <[email-masked]>
Date: Thu, 19 Feb 2009 16:04:49 PST

>On Thu Feb 19 13:59 , Dinesh G Dutt <[email-masked]> wrote:I do not like any solution that in Ethernet doesn't distinguish based on 
>the DA or an immediate ethertype. All control protocols so far have 
>relied on this property (at least on Ethernet) and is easiest to 
>implement in hardware. There is also precedence which makes hardware use 
>existing logic.
>
I agree. We should not create anything in the TRILL header that could conflict with existing L2 methods for differentiation.

We could either define specific solutions for other transports or defining something that can be ignored as redundant
over Ethernet (or other L2s that already have mechanisms to avoid any ambiguity). Ethernet implementations should
not be cluttered with solutions only relevant to PPP.

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

---

From: James Carlson <[email-masked]>
Date: Fri, 20 Feb 2009 08:42:38 -0500

> I agree. We should not create anything in the TRILL header that could conflict with existing L2 methods for differentiation.

There's no "conflict" here other than a self-imposed one.

We can define both control and data frames to run over TRILL (with the
TRILL Ethertype in the Ethernet L2 header), or we can define them to
run apart with the provision that we then need special L2 mechanisms
(separately defined for each medium over which TRILL runs) to
distinguish the two types of frames.

If you do the former, then the special L2 methods for differentiation
based on Outer.MacDA aren't needed.  They're not in "conflict;" they
just are not required to distinguish frames.

I suggest the former because it's more conservative: the fewer hard
dependencies we have on L2 features, the easier it will be to get
TRILL running on other media.  The more we have, the worse it is.

Consider, for example, the use of TRILL over other transports, such as
FR, ATM, and MPLS.  In all of those cases, we lack Outer.MacDA to do
this special differentiation, and we'll need further hacks there.
And, unfortunately, the 4xxx hack that's available for PPP doesn't
exist with those other media.

Moreover, I believe that baking a dependency on Outer.* into the base
specification is itself a mistake.  This forces the future "TRILL Over
Foo" documents to rewrite parts of the base specification: the PPP
document will have to say something like, "ignore all parts of the
TRILL base specification that mention Outer.MacDA; they're wrong, and
this document is right."

I think that telling readers that the base needs to be modified to
accomodate new transports means that it wasn't factored correctly.
Those future documents shouldn't come with patches for the base
document.

And then there's the MTU issue.  Running IS-IS unencapsulated means
that the IS-IS implementation needs to somehow "know" about the TRILL
header overhead in order to do the padding correctly, even though it's
not using the TRILL header at all.

> not be cluttered with solutions only relevant to PPP.

I think "only relevant to PPP" may be a short-sighted way to look at
this.  I don't want the base document cluttered with things that can
only work if the underlying medium is exactly Ethernet, and are broken
otherwise.

We might have a path towards agreement if we talk about "ignored as
redundant" here.  I'd be fine with requiring the use of a special
Outer.MacDA to distinguish IS-IS (control) frames when TRILL is run
over Ethernet, _provided that_ the Ethertype is always TRILL for those
frames, the TRILL header is always present, and the TRILL header
distinguishes the control frames.

sgai writes:
> I completely agree with Caitlin and I prefer to define "specific solutions
> for other transports", if needed. For the moment I don't see the need.

I don't believe that we can or should write a base document that makes
unwarranted assumptions about the underlying medium.

Protocols have a long history ahead of them.  I don't think we can
predict that they'll run over Ethernet alone, in all cases, and
forever.

-- 
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: Radia Perlman <[email-masked]>
Date: Sat, 21 Feb 2009 12:36:11 -0800

I think this would reach consensus more easily if people would list all 
the proposals, rank them according to their
own preference, and perhaps editorialize about each one as well. But 
mostly, make it clear which proposals you like,
which proposals you can live with, which proposals you think won't work 
at all...all in one email.

Thanks,

Radia

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Feb 2009 10:45:31 -0500

> at all...all in one email.

I'll try to summarize the options discussed so far, based on the list
that you gave to start this thread, and then follow up with my own
ranking.

  a) "Per-L2 Mechanism"

     Use Outer.MacDA on Ethernet to distinguish TRILL IS-IS messages,
     with no other encapsulation (use Outer.Length instead of
     Outer.Ethertype, and use LLC).  On PPP, use a separate protocol
     number (likely 4xxx) to distinguish the IS-IS messages from data
     messages (0xxx).  On other media, find some local mechanism to
     distinguish these messages.

  b) "The Version Field Hack"

     Set Outer.Ethertype to be TRILL for TRILL IS-IS messages, and use
     the fact that the "V" field in the TRILL header is currently
     binary '00', while the first octet in a valid IS-IS message is
     hex 83 and thus would be binary '10' to distinguish the two
     messages.

  c) "Per-L2 Mechanism, Part Deux"

     Use Outer.MacDA on Ethernet to distinguish TRILL IS-IS messages
     (as in [a] above), and use a special "sub-protocol" field
     everywhere else.

  d) "The Single Protocol"

     Use Outer.Ethertype to distinguish all TRILL messages.  Change
     one of the "R" bits in the TRILL header to be a "command/data"
     bit: if set, then the message is IS-IS, and the normal IS-IS
     message follows the TRILL header directly.  If clear, then the
     message is data, and can be forwarded.

For options (b) and (d), on Ethernet (and other media where it
matters), reserve a multicast address for TRILL IS-IS to use in
Outer.MacDA, so that monitoring applications can listen selectively
for these messages.  (The Outer.MacDA does *not* indicate message type
for either of these options.  Outer.Etherype indicates protocol, and
some fixed offset in the TRILL header indicates type of message.)

---

From: James Carlson <[email-masked]>
Date: Tue, 24 Feb 2009 09:07:56 -0500

With (apparently?) little dissent on the option summaries, my ranking
and commentary would be:

  d) This is by far my most preferred solution.  It matches what we do
     in other protocols, and even has non-IETF precedent with
     hardware-friendly protocols like HDLC.

     By far the most important benefit of this solution is that it
     makes the base protocol specification (as well as the base
     protocol itself) lower-layer agnostic by removing the need for
     explicit dependencies on Ethernet-specific data.  It becomes
     trivial to map TRILL onto other transports, including ones that
     we haven't thought about yet.  (Tunnel through L2TP, anyone?)

  b) It's a brutal hack, but I could live with it.  It at least
     preserves the (important to me) L2-agnostic mapping.

  a) This isn't very good.  It means that the base document needs to
     be modified by (or will be in conflict with) future documents, so
     it's obviously not very general (or "base") at all, and it's
     substantially unclear whether future mappings over other media
     will in fact work without more serious kludges.  Each one will at
     least need to be different, which is a source of needless
     complexity.

     I suppose I could barely live with it if the alternative is that
     we simply cannot reach any rough consensus, and thus the protocol
     itself is doomed.  But I'd want to try many other things first.

  c) I think this one is just pointless, and I'd have a hard time
     living with it.  The new sub-protocol field is tantamount to
     using a flag in the header (as in option [d]), so it really has
     no obvious advantages over that solution.  It has the serious
     detraction that "the" TRILL header becomes effectively different
     on different underlying media -- complicating packet decode
     needlessly.  And it doesn't solve the problem that the base
     specification is still dependent on Ethernet for the outer
     header, and thus the document will still be in conflict with
     future mappings over other media.  It's the worst of all worlds.