Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-02.txt

From: [email-masked]
Date: Thu, 06 Jan 2011 07:45:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title           : PPP TRILL Protocol Control Protocol
	Author(s)       : J. Carlson
	Filename        : draft-ietf-pppext-trill-protocol-02.txt
	Pages           : 6
	Date            : 2011-01-06

The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol
(LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links.  This document describes support for
Transparent Interconnection of Lots of Links (TRILL) Protocol,
allowing direct communication between Routing Bridges (RBridges) via
PPP links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: James Carlson <[email-masked]>
Date: Sun, 16 Jan 2011 14:23:01 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-02.txt

I'm starting a working group last-call comment period for this draft.
The new version incorporates changes for all of the comments received up
to this point.

Last call will run for two weeks.  Please submit any comments,
questions, or concerns you might have to me or to the [email-masked]
mailing list (or both) on or before Sunday, January 30th, 2011.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 21 Jan 2011 21:37:57 -0500

I have reviewed this draft and believe it should be advanced as a
proposed standard but I suggest the following minor tweaks:

I believe references are not allowed in an Abstract so you may have to
explicitly say "RFC 1661" if necessary, or perhaps this reference can
just be moved to the first occurrence of PPP in the body.

Section 2.3, in the first sentence, for clarify suggest changing "the
IS-IS Payload" with "the IS-IS Payload, starting with the IS-IS
Network Layer Protocol Identifier byte (0x83),"

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

On Sun, Jan 16, 2011 at 2:23 PM, James Carlson <[email-masked]> wrote:
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: James Carlson <[email-masked]>
Date: Sat, 22 Jan 2011 09:23:20 -0500

> Network Layer Protocol Identifier byte (0x83),"

Both changes sound good to me; thanks!

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 24 Jan 2011 11:51:05 -0500

> mailing list (or both) on or before Sunday, January 30th, 2011.
Caveat: I'm not familiar with TRILL.  Radia does great work, but she's
always been rather biased in favor of IS-IS.  I remember a debate at
Interop '91 (or was it '92)....  But you have me at "Algorhyme"! ;-)

In any case, I disagree with section 3 item 3 regarding the OUI.  I'm a big
fan of completely finishing a specification, not leaving holes for later.
And a bigger fan of zero configuration that eliminates even the possibility
of an additional operational consideration!

IIRC, IETF now has an OUI.  Back in the day, we'd use something in the
CF0000 series (see [RFC-2153]).  Either should work OK.

PPP has a Magic Number, guaranteed to be unique between PPP interfaces on
the same device.  You should combine it with the OUI.  Simply require it
during LCP negotiation, as so many other PPP RFCs do already.

---

From: James Carlson <[email-masked]>
Date: Mon, 24 Jan 2011 12:05:47 -0500

> of an additional operational consideration!

I agree that it'd be nice to fill in this hole, but I'm not so sure how
to accomplish that task.  I don't think IETF OUI plus LCP Magic Number
works -- the Magic Number value is unique for a given endpoint on a
given link, but is not guaranteed to be unique across a network.  But
the IS-IS System ID number does need to be unique across the network,
and its construction based on MAC addresses normally protects that
requirement.

One way to avoid the hole would be to outlaw the use of systems that
lack any way to form an IS-IS System ID, but that seems a little harsh.
 Forcing that corner case to use manual configuration is distasteful,
but the alternatives seem worse, at least to me.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 24 Jan 2011 12:52:36 -0500

> during LCP negotiation, as so many other PPP RFCs do already.

Upon further reflection, the IETF OUI won't work, because that would
require either truncating the Magic Number (rendering it less likely to be
unique), or using a EUI-64 form to make enough room for the full 32 bits.

But I don't see any ability in the TRILL draft to use the EUI-64 format.

So, you'd have to use the CF0000 series.  AFAICT, the TRILL protocol never
uses that System ID as the next hop destination (please correct me).  It
uses its own multicast value, so there should be no conflict.

I'd recommend registering the CFFFxx series to add a Magic Number.

The CF0000 series was not originally intended to be used outside of PPP
Vendor Extensions, and thus never appears over an actual Ethernet link....
This would be a first.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 24 Jan 2011 13:29:42 -0500

> and its construction based on MAC addresses normally protects that
It must be nice to live in a world with unique MAC addresses!  In my
experience, I've run into rather a lot of them that are not -- and it
will be much worse in this cross-linked multi-media environment.  Many
vendors think that it's OK to reuse the MAC address for different link
speeds and types.

The likelihood that two D-Link boxes have the same MAC is something on
the order of 2**8 (and was *every* box for about 2 years)!  I've had
problems with Linksys, Intel, 3Com, etc. ad nauseam.

The only way that the Magic Number has any significant chance to ever be
non-unique would be a very large number of PPP-only bridges in the network,
on the order of 2**16.  Probably best to stick an IP router in there....

If the PPP-only bridges are talking to each other, there will *never* be
any non-unique numbers.  That's the more likely case of centrally
located PPP-only bridges.

> lack any way to form an IS-IS System ID, but that seems a little harsh.

And contrary to the whole point of PPP.

> but the alternatives seem worse, at least to me.
Well, many boxes these days have the ability to over-ride the default,
but it would be nice to have a default mechanism.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 24 Jan 2011 14:05:59 -0500

> vendors think that it's OK to reuse the MAC address for different link
I'm staring at the TRILL draft, and cannot find anything in the protocol
to detect, eliminate, or resolve duplicate System ID numbers.  Obviously,
I'm missing something.  Please advise.

> on the order of 2**16. Probably best to stick an IP router in there....
To elaborate, I've an old story to tell.  Once upon a time, Michigan State
University supposedly had the world's largest bridged ethernet, covering
many square miles.  Performance was abysmal.  But once I stuck a 286 box
with KA9Q net (this was circa 1985) between the computing center and
engineering, performance miraculously improved!

(The problem turned out to be fragments inserted by the IBM in the
administration building next door to the computing center.)

Thus, I got the routing religion....  Never use a bridge where a router
could be used instead.

I really doubt we'll ever see more than one or two PPP-only Rbridges in a
single installation.  The point being that PPP is vastly more robust than
ethernet -- and you shouldn't let the good enough (ethernet) be the enemy
of the better (PPP).

> located PPP-only bridges.
Of course, this assumes that the PPP Magic Number has been implemented
correctly, and it checks the number against all its interfaces to avoid
loops.  It also assumes you haven't deployed Junipers with the fairly evil
"ppp magic-number ignore-mismatch".

---

From: James Carlson <[email-masked]>
Date: Mon, 24 Jan 2011 15:41:55 -0500

> I'm missing something.  Please advise.

I don't believe that anything can or will do that.  It's assumed into
existence, as far as I understand.

The System ID is used (among other things) for pseudonode generation and
TRILL nickname resolution.  If those aren't unique, then my
understanding is that the network will fly to bits.

I'm not the IS-IS expert here.  If someone else (preferably on the
RBridge mailing list) has an opinion about running a TRILL IS-IS network
where some of the nodes using only point-to-point links have System IDs
that are possibly non-unique, then now is the time to speak up.

But I certainly don't feel comfortable endorsing this sort of usage in
the PPP TRILL draft without review by at least the TRILL group, and
probably the IS-IS group as well.

> Thus, I got the routing religion....  Never use a bridge where a router

Indeed.  I agree completely, though I don't think it's really the
problem at hand.  If the user has PPP TRILL links, he's already decided
(for whatever reason) that he wants to bridge.

> "ppp magic-number ignore-mismatch".

I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
check across all of the node's interfaces.  Off hand, I don't know of
any that do that, and I do know of a few implementations where such a
test would be architecturally impractical (if not outright impossible).

In any event, I think this is a detour: the real issue is that the IS-IS
System ID must be unique across the IS-IS campus, and PPP's Magic-Number
option doesn't have that quality, even if it has the checks you're
suggesting.

With Ethernet, the assumption is that MAC addresses among systems that
speak IS-IS are unique per the standards.  Whether any vendor is able to
achieve that and/or whether relying on MAC uniqueness is a smart thing
to do is possibly an interesting topic, but I think is certainly one for
a different mailing list.  It doesn't involve PPP.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 24 Jan 2011 17:44:09 -0500

> understanding is that the network will fly to bits.
There is some text about resolving nicknames that aren't unique.  Nicknames
aren't deterministic on the System ID, though.  They're small, so they have
a 2*8 average chance of collision.  (Section 3.7)

I cannot find a description of pseudonode generation.  (Or even a
definition for "pseudonode".)

> probably the IS-IS group as well.
OK, let's wait a bit.

The questions are:

  - How does TRILL handle System IDs that are not unique?

  - Are System IDs ever used in the ethernet source or destination fields?

> test would be architecturally impractical (if not outright impossible).
The whole point is to avoid loops.  It is "a unique number".  You cannot
avoid a loop with your *own* interfaces without checking against any
existing interfaces to see whether your chosen number is unique....

Certainly, I'd never expect connecting serial port 1 to serial port 2
on the same machine would ever pass the magic number test.

(Sometimes I wonder, how many more details must we write in specifications,
when something this obvious is missed by some implementers?)

> a different mailing list.  It doesn't involve PPP.
I don't like assumptions.  That's a tautology.

If the proven existing MAC uniqueness in the field is already *less* than
known mathematical uniqueness of the PPP Magic Number, then there's no
PPP-specific issue to be solved.  In either case of conflict, then manual
configuration is required.

The chance of PPP collision is *much* rarer.  Automatic PPP configuration
should be part of this specification.

---

From: James Carlson <[email-masked]>
Date: Mon, 24 Jan 2011 20:16:45 -0500

> definition for "pseudonode".)

It's part of RFC 1142.  I'm no IS-IS expert; it could possibly be just a
LAN-type feature.

The bottom line, though, is that I'm not willing to define a new mode of
operation for IS-IS on my own.  If there's some documentation of how
existing IS-IS systems with only point-to-point links operate without a
System ID, I'll be happy to provide a pointer to it along with an
appropriate synopsis to make it as clear as possible.

I am unable to locate any documentation of that sort.  If you have
pointers, please supply them, and I'll incorporate.

I wrote this draft as a favor to the RBridges chair to describe how the
protocol would work on some medium other than Ethernet.  The TRILL
protocol is designed so that it should be medium-agnostic (at least on
the transport side), but without an existence proof, it's hard to know,
and that's what this draft helps accomplish.

But I don't intend this draft as an extension or modification of IS-IS
in any way.  If extensions are required, then I think it would be best
to withdraw the draft and call it a day.  Someone else will have to
design whatever extensions you and the other reviewers feel are
necessary.  (I don't believe any such extensions are required, but if
that's the case, then I'm out.  I can't do that work.)

>  - How does TRILL handle System IDs that are not unique?

I do not know.  But I do know that RFC 1142 goes out of its way to say
that MAC addresses are unique, and that System IDs must also be unique.
 As far as I can tell, it's just assumed.

But this is *not* the IS-IS working group.  I think any questions about
how IS-IS does or does not work really ought to be directed to that
group.  I can't answer them in any reasonable way, and I'm pretty sure
that questions like that are just plain out of scope for this draft.

For that matter, this draft also doesn't address TRILL itself.  It only
addresses the operation of TRILL over PPP links.  If there are design
problems in TRILL itself -- if there needs to be some magic in TRILL
that checks for the "impossible" duplicate System IDs -- then I believe
that this is a generic issue with TRILL, and it should be addressed
outside the scope of the last call for this draft.

If there's a fix to the problem you're describing, then surely it's not
dependent on PPP for operation.  Right?

>  - Are System IDs ever used in the ethernet source or destination fields?

Not that I'm aware of.  They are used in the generation of LSPs as part
of IS-IS, though.

> existing interfaces to see whether your chosen number is unique....

It's to avoid looped-back interfaces.  That's exactly what the RFC says.
 Not "avoid loops."  The RFC goes to great length to describe when and
why an implementation must generate a new Magic Number value due to
conflict, and at no point does it describe comparisons against any value
except the two values used by the two peers on the link.

I agree that it'd be nice to have it do more, and that what you're
suggesting sounds reasonable.  However, it's certainly not what the RFC
says.

And worse still, even if the RFC were to describe the mechanism you're
suggesting, IT WOULD NOT HELP!  The requirement in IS-IS is for
network-wide uniqueness, and merely checking all of your own links --
but not those of all of the nodes in the network -- is insufficient to
meet that goal.  Nothing PPP does can help with that.

Thus, I believe this entire discussion about the operation of the LCP
Magic-Number option is without a point.

> when something this obvious is missed by some implementers?)

If you'd like to publish an update to RFC 1661 with this sort of
restriction, that sounds fine to me.  For what it's worth, though, I
can't say I know of any implementations that will pass this new stricter
test.

In particular, the common CMU/ANU/samba.org pppd implementation would
not pass.  It has no means of comparing Magic-Number option values
across links.  The control portion of each link runs in a completely
different address space -- different processes.  It'd require a database
similar to the one currently used for RFC 1990 E-Ds and MP in order to
implement it, and given the sorts of problems seen with that, it's not
what I'd call an improvement.

> should be part of this specification.

I still don't understand why this draft has to define this new special
usage.  We're talking about a corner case out of a corner case -- a
special TRILL-speaking system with PPP links but that has zero Ethernet
interfaces.  Who is going to build such a beast?  And why?

In the unlikely case that someone does build that thing, I'd be happy to
let that person define exactly how the required IS-IS System ID is
computed, formed, configured, guessed, or drawn carefully out of the
ether.  For the simple case of allowing a TRILL-speaking system that
already has its own means of deriving a System ID (whatever that may be)
to use PPP links between other cooperating systems, I believe the
existing text is sufficient.

To be clear: TRILL over PPP allows the packets to be exchanged in a
reasonable manner.  Unlike Ethernet, it does not come with a burned-in
"guaranteed globally unique" MAC address, and thus any existing text in
TRILL and/or IS-IS documents that assume the existence of such an
address on at least one link in the system -- such as section B.2.1.3 of
RFC 1142 -- will have to look elsewhere for that value.  PPP can't
supply it.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 Jan 2011 02:35:30 -0500

Hi,

> I'm missing something.  Please advise.

You are looking in the wrong place. The unique System ID requirement
is an IS-IS requirement.

It is my impression that manufacturers of ISIS routers either allocate
a MAC address under their OUI to use as System ID or use the MAC
address of one of their interfaces. Maybe, in this instance, they are
more careful to not duplicate from some other box they built. But it
doesn't matter what they do. It's an IS-IS requirement and their
problem.

Maybe the draft should just say less about this.

Donald

PS: Current traveling so I'm a bit out of phase...

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 Jan 2011 02:58:00 -0500

Hi,

> a 2*8 average chance of collision.  (Section 3.7)

Nickname resolution is dynamic so collisions get resolved.

> definition for "pseudonode".)

That's because all of that is part of IS-IS. You need to start with
ISO 10589, the 2002 edition.

>  - How does TRILL handle System IDs that are not unique?

System IDs are used to uniquely identify IS-IS router in the link
state database. There is no TRILL specific stuff related to non-unique
System IDs. It's all IS-IS.

>  - Are System IDs ever used in the ethernet source or destination fields?

There is no requirement to ever to that. Since they are the same size
you can. As far as I know (which isn't that much), most manufacturers
of IS-IS switches either allocate an MAC address they control to use
as the System ID for a box or, a bit more commonly, use the MAC
address of one of the boxes interface, such as the numerically lowest
interface MAC address.

There is no requirement for the MAC interfaces of RBridges in a campus
to all have unique addresses as long as all the RBridges connected to
a particular link have unique MAC addresses over that link. But the
System IDs must be unique across the campus as per IS-IS subnet
independent functions requirement.

> configuration is required.

See above. MAC address uniqueness isn't the same as System ID
uniqueness although in practice they might be conflated sometimes.

Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 Jan 2011 13:08:50 -0500

Hi James,

I think your position below is reasonable. The System ID of an IS-IS
router is certainly not required to be any sort of MAC address, it
just has to be a 48-bit quantity unique among the IS-IS routers whose
link state entries need to be distinguished.

Perhaps Section 3, point 3, should be reworded to something like: "In
the case of an RBridge with only PPP links, the practice of using the
MAC address of an interface for the IS-IS System ID will not be
available. The implementor will have to use other means, such as
deriving a System ID from a MAC address allocated to the device as a
whole, to assure that it has a campus-wide unique System ID."

Thanks,
Donald
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

On Mon, Jan 24, 2011 at 8:16 PM, James Carlson <[email-masked]> wrote:
> Pppext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pppext
>

---

From: James Carlson <[email-masked]>
Date: Tue, 25 Jan 2011 13:17:23 -0500

> whole, to assure that it has a campus-wide unique System ID."

That seems quite reasonable to me.  I just want to steer clear of
writing too much of the IS-IS requirements into this draft, as I think
the overall system design implications are out of scope.

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 25 Jan 2011 10:31:55 -0800

Hi James,

IMHO there should be no mention of IS-IS in the PPP draft. As IS-IS is
a control plane protocol (we could as well use static Rbridge route
entries - a requirement we have heard from 2 of our customers) and PPP
is the data plane.

Thanks,
Vishwas

---

From: James Carlson <[email-masked]>
Date: Tue, 25 Jan 2011 14:04:13 -0500

> entries - a requirement we have heard from 2 of our customers) and PPP

I assume you're talking about the discussion of the System ID issue, and
not the TLSP Packet Format described in section 2.3 for carrying IS-IS
packets.  (If you *do* mean TLSP, then I'll probably need some
additional clarification.)

I certainly agree with the sentiment (I don't like duplicating
documentation at all, particularly for this issue), but the existing
notation about MAC addresses (and the lack of them on PPP) was added at
the behest of other reviewers who found that it was confusing to match
up the PPP TRILL draft with the primary TRILL documentation without some
indication that there are differences here.

I find I'm walking a narrow line.  I want to provide a little guidance
so that it's clear what's expected here, but I also want to avoid either
just copying hunks of the TRILL and IS-IS documentation or (worse)
carving out special exceptions.  I probably can't please everyone.

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 26 Jan 2011 13:20:34 -0500

> indication that there are differences here.
I agree with the other reviewers.  Pretty hard to understand TRILL over
PPP without mentioning System IDs and the lack of MAC addresses.

This is the first Last Call we've had on the list for years, so I wasn't
paying sufficient attention.  I'm sure we'll iron things out.

> carving out special exceptions.  I probably can't please everyone.
Probably not.  But it's fundamentally wrong to specify a configuration
requirement for two protocols that are both premised on auto-configuration!

I'm sorry that I was off-line yesterday.  We've had responses about the
requirements, and that clarifies things immensely.  But I'm busy cleaning up
yesterday's mess today.  I promise some text tomorrow....  TIA!

---

From: James Carlson <[email-masked]>
Date: Wed, 26 Jan 2011 14:47:10 -0500

> requirement for two protocols that are both premised on auto-configuration!

The other possible solution to avoid manual configuration (as I think I
mentioned) is to outlaw the use of TRILL systems that have only PPP
links and that also have no built-in (implementation-dependent) means of
acquiring a System ID automatically.

That's obviously possible, but besides being draconian in nature (how is
it my business how you plan to work with network administrators?), it
seems to strike a bit too close to the fundamentals of IS-IS.

In other words, I think I can point out the potential issue that exists
over in IS-IS to readers who might not be aware that (as part of an
overall system design, not as part of PPP TRILL itself) they could be
stepping in an area that lacks good solutions, but I don't think I
should say anything here that's at the level of requirement.  It's not
my place to repeat IS-IS requirements.  I can only do so badly and
out-of-sync with the original.  ;-}

Informative works for me on this issue, but normative doesn't.

> yesterday's mess today.  I promise some text tomorrow....  TIA!

Delay is not a problem.  I set a standard two-week timer to make sure
that folks would follow up.  But if there's still discussion going on at
that point, I'll continue with it as long as necessary to close it out.
 (Or until I remember that I have other things to do, I suppose ...)

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Jan 2011 15:08:52 -0500

Hi,

> PPP without mentioning System IDs and the lack of MAC addresses.

I don't understand why you say that. Seem to me that TRILL over PPP
just involves the formats, code points, and PPP procedures. Anyway, it
isn't clear to me that anyone will build a practical RBridge that
doesn't have a MAC address Ethernet interface even if it is just a
virtual internal interface for a virtual internal end station. If that
doesn't exist, you can't really address the RBridge for management or
maintenance.

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

---

From: James Carlson <[email-masked]>
Date: Wed, 26 Jan 2011 16:38:36 -0500

> doesn't exist, you can't really address the RBridge for management or

Sure, you could.  It would just have to be addressed via IP (e.g., via
SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.

One could imagine a large TRILL bridge designed for telecom applications
exclusively on the interior of the cloud, where the only possible links
are point-to-point; no Ethernet need apply.

Whether anyone ever builds that beast -- and, if so, whether it lacks
any built-in mechanism for automatic System ID assignment -- is a
different question.

What we're really discussing is whether failing to cover this case with
some sort of automatic resolution is a hole in the specification (as I
think Mr. Simpson is contending), or whether it's just an unlikely
corner that implementors should be warned away from (as I believe).

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 Jan 2011 09:33:34 -0500

Hi James,

> SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.

Really? RBridge don't route on IP addresses. They route based on
nickname and, on ingress, they convert to nickname from MAC/VLAN. How
are you going to get an RBridge to route on an IP address?

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jan 2011 09:50:31 -0500

> are you going to get an RBridge to route on an IP address?

You provide it with access to a management network, perhaps also through
PPP.  This could be done via separate interfaces or, if desired, by
running IPCP in parallel with TRILL on the existing PPP links.

Who said all management must be in-band with the data network?