Subject: Re: [rrg] definitions - alternate view

From: [email-masked] (Noel Chiappa)
Date: Sat, 4 Apr 2009 11:50:49 -0400 (EDT)

> From: William Herrin <[email-masked]>

    > Address: Any element in a network packet used to calculate the packet's
    > next hop. 

That would make an MPLS tag an "address". Somehow I don't think so. (Not to
mention the TOS field, if anyone is still using TOS-dependent routing.)

In general, I think we're at a point of diminishing returns on discussing
terminology.

Existing terms (identifier, address, locator) are particularly problematic as
they already have meanings in most people's minds, and changing them is
nearly impossible. Just give it up.

If we really need a name for some particular crisp definition (such as the
one above), pick a new word/phrase, don't try and morph an existing word.

	Noel

---

From: William Herrin <[email-masked]>
Date: Sat, 4 Apr 2009 18:25:14 -0400

On Sat, Apr 4, 2009 at 11:50 AM, Noel Chiappa <[email-masked]> wrote:
>    > From: William Herrin <[email-masked]>
>
>    > Address: Any element in a network packet used to calculate the packet's
>    > next hop.
>
> That would make an MPLS tag an "address". Somehow I don't think so.

Why not? What characteristics of what you think of as an address are
missing from the typical use of an MPLS tag?

> (Not to

Was TOS ever used in the dynamic part of a routing protocol?

If TOS is used in the forwarding decision within a particular scope
then it is part of an address within that scope. If that scope happens
to be a static route on a single piece of equipment (or a static nudge
to a dynamic route) then it's well outside the RRG's area of interest.

The same goes for Linux Virtual Server (LVS) which routes packets
based on the TCP transport ID. The TCP transport ID is an address
within that scope, but the scope is limited to a single server
cluster.

> one above), pick a new word/phrase, don't try and morph an existing word.

If the chair is amenable to that idea, so am I. At the moment I'm
endeavoring to remove the fuzz from the existing terms as the chair
requested.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Tony Li <[email-masked]>
Date: Sat, 04 Apr 2009 16:24:22 -0700

Hi Bill,

> missing from the typical use of an MPLS tag?

Well, for one thing, an MPLS label is relative.  Label value X is only 
meaningful pairwise between a pair of routers along the path.  The same 
value X between any different pair of routers will imply a separate LSP 
and thus a different path entirely.

> Was TOS ever used in the dynamic part of a routing protocol?

Yes.  OSPF used to have TOS support.

> endeavoring to remove the fuzz from the existing terms as the chair

Normally, I would love that idea.  However, our specific request is that 
we define the terms locator and identifier.

Regards,
Tony

---

From: William Herrin <[email-masked]>
Date: Sat, 4 Apr 2009 19:41:09 -0400

On Sat, Apr 4, 2009 at 7:24 PM, Tony Li <[email-masked]> wrote:
> value X between any different pair of routers will imply a separate LSP and
> thus a different path entirely.

Tony,

Maybe I misunderstand how MPLS is used with respect to Internet
routing. Please correct:

As I understand it, an IPv4 packet arrives at [A], an MPLS encoding
router. The router looks up the destination in its routing table and
determines that [B], a border router to another system, should deal
with the packet next. So, [A] tags the packet with "555" which means
"send to router B," and then passes the packet router C which appears
to currently have the shortest path to [B]. Router C knows that tag
555 means pass the packet to [B], so it sends it to router D which
appears to currently have the shortest path to [B]. Rinse and repeat
until it gets to [B] which knows that it owns tag 555 which means
decapsulate the packet back to IPv4 and route it using the BGP table.

In that use case, tag 555 is most certainly a locator within the scope
of the MPLS system.

I'll concede that MPLS tags are general purpose and can be programmed
with other functions besides that of a locator. In theory, you could
define an MPLS tag to mean "beep the speaker and then pop the stack."
In practice, MPLS is used to define locators with an AS-interior scope
so that only the AS border routers need to carry the BGP table and
make BGP routing decisions.

Or have I misrepresented how MPLS is being used as it pertains to
Internet routing?

Regards,
Bill Herrin

---

From: Tony Li <[email-masked]>
Date: Sat, 04 Apr 2009 17:03:59 -0700

Hi Bill,

> In that use case, tag 555 is most certainly a locator within the scope

Even in the simplest cases, the label value is almost always allocated 
on a hop-by-hop basis.  Thus, 555 is only valid for a single hop and the 
router that receives this will SWAP it for another value.

The only cases where 555 itself would act as a true locator would be if 
someone is doing global label allocation, and that's very rare, AFAIK.

There are many, many more complicated uses, especially using TE, that 
would also argue that a label itself is nothing but an index into a 
computed path.  The only time you'd have an object that truly would seem 
to "name a point of attachment" is during signaling, when the RSVP 
Explicit Route Object (ERO) would contain the full path.  Note that this 
is somewhat different than how we think of a locator, as normally we 
consider a locator to be an absolute name of a location, not the 
relative path to a location.

Tony

---

From: William Herrin <[email-masked]>
Date: Sat, 4 Apr 2009 20:43:52 -0400

On Sat, Apr 4, 2009 at 8:03 PM, Tony Li <[email-masked]> wrote:
> Even in the simplest cases, the label value is almost always allocated on a
> hop-by-hop basis.  Thus, 555 is only valid for a single hop and the router
> that receives this will SWAP it for another value.

Hi Tony,

Like a frame relay DLCI. Got it now.

I still argue that it's a locator under the locator definition I used.
Remember, I didn't define "locator" as point of attachment here. I
defined it as a type of address not used to construct an identifier
while I defined an address as an element used to determine the
packet's next hop.

Nothing in my definition of address or locator precludes translation,
even on a hop by hop basis. Translation is only obstructed in the
identifier where it might interfere with the persistence requirement.

> Note that this is somewhat different
> than how we think of a locator, as normally we consider a locator to be an
> absolute name of a location, not the relative path to a location.

Yeah, I get that. I'm suggesting that how we've been thinking about
locators and identifiers is not quite right. The error was revealed by
our attempt here to give them more precise definitions. They're
eluding our attempts at rigor.

Regards,
Bill

---

From: Tony Li <[email-masked]>
Date: Sat, 04 Apr 2009 20:52:46 -0700

Hi Bill,

> Like a frame relay DLCI. Got it now.

Exactly.

> identifier where it might interfere with the persistence requirement.

I agree that translation is not that big a deal as long as it isn't 
happening due to a namespace boundary or scope boundary (e.g., NAT).

However, I'm still not ready to roll labels, VCI, DLCI, and X.25 paths 
(and for that matter, the Atomic link layer path) into our definition of 
'locator'.  I'd much prefer to take the opportunity to distinguish those 
and use something like 'path' to describe those.

> eluding our attempts at rigor.

Ok, enlightenment is most welcome.  ;-)  Must be accompanied by 
alternate text tho.

Cheers,
Tony