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

From: Donald Eastlake <[email-masked]>
Date: Sun, 9 Jan 2011 21:48:01 -0500

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Jan 6, 2011 at 10:45 AM
Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-02.txt
To: [email-masked]
Cc: [email-masked]

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/
_______________________________________________
Pppext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pppext

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

---

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]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

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

William Allen Simpson wrote:
> 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!

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: James Carlson <[email-masked]>
Date: Mon, 24 Jan 2011 15:41:55 -0500

William Allen Simpson wrote:
> 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.

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
> could be used instead.

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.

> 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".

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: James Carlson <[email-masked]>
Date: Mon, 24 Jan 2011 20:16:45 -0500

On 1/24/11 5:44 PM, William Allen Simpson wrote:
> On 1/24/11 3:41 PM, James Carlson wrote:
> 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".)

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.)

> OK, let's wait a bit.
> 
> The questions are:
> 
>  - 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.

> 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....

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.

> 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?)

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.

> 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.

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,

On Mon, Jan 24, 2011 at 2:05 PM, William Allen Simpson
<[email-masked]> wrote:
> On 1/24/11 1:29 PM, William Allen Simpson wrote:
>>
>> On 1/24/11 12:05 PM, James Carlson wrote:
>>>
>> 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.
>>

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...

>> 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....
>>
> 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.)
>
> 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).
>
>> 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.
>>

---

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]

---

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: James Carlson <[email-masked]>
Date: Wed, 26 Jan 2011 14:47:10 -0500

William Allen Simpson wrote:
> On 1/25/11 2:04 PM, James Carlson wrote:
> Probably not.  But it's fundamentally wrong to specify a configuration
> 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.

> 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!

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,

On Wed, Jan 26, 2011 at 1:20 PM, William Allen Simpson
<[email-masked]> wrote:
> I agree with the other reviewers.  Pretty hard to understand TRILL over
> 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?