Subject: RE: Last call on LSP Ping

From: "Gray, Eric" <[email-masked]>
Date: Mon, 9 Dec 2002 11:24:20 -0500

Curtis,

	You probably need to remember that it's generally
not considered polite to speculate cynical motivations 
for why people object to an idea that you have no 
particular objection to.  Your stated belief that people 
are "grasping at straws" in objecting to the use of the 
127/8 address range because they object to MPLS-Ping may 
be completely false in every case - and is certainly so 
in my own case.

	Please try to avoid bringing things to the personal
level.  It's highly unprofessional, at the very least,
and certainly not conducive to rational discussion.

	I object to the use of this address range for the
purpose that has been stated thus far.  The reason why I 
object to it, is that I see it as pointless and possibly 
problematic.  I have no objection to MPLS-Ping itself.

	From a posting by George Swallow (roughly 7:00 
P.M. on 12/05/02 - see excerpt below), I got the clear 
impression that the use of this address range was 
intended to allow a sender to "tickle" all of the paths 
that might be used by an ECMP load sharing set of LSPs.  
If that is the case, this is hopelessly useless for that 
intent, since the last byte in the IP destination address 
is NOT going to be used for ECMP load sharing of LSPs in
many reasonable LSR ECMP implementations.  It is not even 
guaranteed to be used in IP forwarding.  There are, for
example, perfectly reasonable hashing algorithms that use
the first two bytes in both the source and destination IP
addresses.  There are other ECMP hash algorithms that use
SIPA exclusively.  What is the point in using the 127/8
address range if any of these are in use?

	If there is another reason for using this address 
range, it either has not been stated, or I missed it.  If
there is a good reason to do it, I would not object to it.
But there is not and - IMHO - there is a non-zero risk in
using it.  In other words, cost is possibly higher than
we know and benefit is definitely lower than we seem to
be led to believe.

	So I object to the use of the address range, not to
the usefulness of MPLS-Ping.  

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> ----- Excerpt from a message from George Swallow -------
> From: George Swallow [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 7:01 PM
> To: [email-masked]
> Cc: George Swallow; [email-masked]; [email-masked]
> Subject: Re: Last call on LSP Ping

[...]

>> The suggestion to randomly choose IP destination addresses from the 127/8
>> block is, presumably, the way to ensure that the various paths created by
>> equal cost load splitting get exercised.  The question is, how many pings

>> do you need to send in order to get good coverage?  
>
> Obviously this depends on the number of ECMPs that exist.  Which is
> both a function of the topology and the number of hops between the
> source and destination.  If you have better suggestions on how to do
> this I'm quite eager to hear them.  This is the best we've been able
> to come up with so far.

[...]

> ----- Original Message [from Curtis Villamizar] -----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Saturday, December 07, 2002 6:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Last call on LSP Ping
> 
> 
> In message <0536FC9B908BEC4597EE721BE6A35389014CFCB5@i2km07-
> ukbr.domain1.system
> host.net>, [email-masked] writes:
> > > > George....I think the point Shahram was making it is not
> > > even allowed
> > > > outside the host/source box according to the text quoted
> > > from the RFcs
> > > > below.  Wrapping it in some other package (any, not just
> > > MPLS) is still
> > > > violating this requirement...and note that it *must* be
> > > placed in some
> > > > package to get across any tranmission medium....IP pkts
> > > don't go raw on
> > > > wires.
> > >
> > > As far as I'm concerned it is within the spirit of the RFCs.  If you
> > > want to insist on the letter of the law, perhaps you should look into
> > > a career as a solicitor.
> > >
> > > ...George
> >
> > George, I am asking a serious question here and I would have appreciated
> a
> > serious answer please.  I'd also like to see some responses to the other
> > issues that have been raised.  My experience to date suggests one only
> gets
> > responses 'when it suits'.  At least others (esp Erics R and G and
> Curtis)
> > have attempted to provide reasoned answers.
> >
> > This stuff is going to get delivered whatever right?....so I want to be
> sure
> > that its as fit for purpose as possible (and that's more than this
> > particular 127/8 point).
> 
> A lot of packets from my site (here at home) go through the Internet,
> all destined to a subnet of 10/8 (in the office).  This (10/8) is also
> not a routeable address covered in the same sections as 127/8 in
> RFC1700 and RFC1812.  Its OK to deliver these packets since they are
> encapsulated in something else.  It is not considered a violation of
> RFC1700 or RFC1812 to forward these across the Internet where 10/8 and
> 127/8 are considered to be "martian packets".
> 
> Going way back to 1992, the mbone tunnels were originally built out of
> source routed tunnels with a multicast destination.  They later
> switched to a tunnelled encapsulation due to performance problems of
> certain routers when handling large volumes of source routed packets.
> This was not considered a violation of RFC1700 or RFC1812.
> 
> There are plenty of precedences for using private addresses inside
> something else.
> 
> In many circumstances, packets with private addresses are tunneled.
> You have to separately look at what happens at the end of the tunnel
> after the encapsulation is stripped off.
> 
> > Here's my understanding of the current position on this specific point:
> >
> > There are (at least) 2 possible cases:
> > 1	127/8 addressed pkts should never leave a box
> > 2	127/8 can always leave a box.....since I can put 127/8 addressed
> > pkts in ATM or FR (or ethernet?) directly.....I see no significant
> technical
> > difference here to the MPLS case that is argued as being justified.
> > [Aside - one could generalise the above case 2 to *any* IP addressed
> packet,
> > or we could make 127/8 a special case]
> 
> 127/8 cannot be forwarded based on the 127/8 destination.  Just as
> traffic from 10/8 can leave a subnet, croos the big-I Internet, and
> reenter a subnet of 10/8, so can a packet be formed with a 127/8
> destination and be encapsulated in something and sent.
> 
> What happens when the outside encapsulation is stripped off also has
> to be examined.
> 
> When the labels are gone, the 127/8 remains and the packet is sent to
> the loopback address.  That is the one exception allowed by RFC1812
> and delivery to the loopback is the explicit intended use of 127/8.
> 
> > Now I just want a ruling that 2 is fine (perhaps as a special case?),
> and as
> > long as its agreed now then that's OK....I don't want this raised by
> someone
> > X months hence after this stuff is being shipped and operators have
> deployed
> > it.
> 
> If you had a legitimate reason to deliver traffic to the loopback
> device on the other end of a FR or ATM link, then putting 127.0.0.1 in
> the destination and a valid UDP payload with a port number for that
> application, then it would be fine.
> 
> There is a legitimate reason for selecting a 127/8 address for this
> application.  Because it is used for a diagnostic we DON"T want it to
> be routeable.  RFC1700 and RFC1812 guarentee that it won't be
> routeable.  RFC1700 and RFC1812 explicitly set this address space
> aside for use with the loopback device.
> 
> > regards, Neil
> 
> Once again, I think the MPLS-ping objectors are simply grasping at
> straws.
> 
> Curtis

---

From: Eric Rosen <[email-masked]>
Date: Mon, 09 Dec 2002 11:36:56 -0500

EricG> If there  is another reason for  using this address  range, it either
EricG> has not been stated, or I missed it. 

Well, what  should the tunnel ingress  put into the IP  destination field of
the "LSP Ping" UDP packet?  We want  the packet to be consumed by the egress
even if the egress  isn't who the ingress thinks it is.   (That's how we get
the  error   response  indicating  that  the  tunneled   packets  have  been
misrouted.)  Thus  we need to  put in a  "well known" address which  will be
interpreted by the tunnel egress as meaning "for me". 

Use of one of the loopback addresses (127.x.y.z) seems to achieve this goal.
I think it's kind of a nifty hack ;-)

As Curtis  has pointed out, there  is ample precedent for  having a tunneled
packet  carry addressing  information  which  is to  be  interpreted in  the
context of the egress.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Dec 2002 12:53:26 -0500

In message <[email-masked]
> be completely false in every case - and is certainly so 

Fine.  Lets hear the technical reasons for the objections.

[btw- I was replying to a request that I elaborate on that.]

> address range if any of these are in use?

I think ECMP processing is broken and that use of the lower 8 or even
24 bits of 127/8 is not the way to handle it.  I'll provide more
detail on ECMP in a later response (there are a number of thread).

> we know and benefit is definitely lower than we seem to

The reason for using it is that 127/8 is never routable so it won't
wander any further than the egress of the LSP due to IP forwarding.
If the LSP is somehow misrouted it is a way of indicating "whoever
gets this please respond".  For LDP the ingress may not know the
routeable loopback address of the LDP endpoint.

> the usefulness of MPLS-Ping.  

OK. And by citing ECMP, you have now cited a technical reason so we
can have a technical discussion.  I'll reply to Eric Rosen's reply to
this and give more detail.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Dec 2002 13:32:34 -0500

In message <[email-masked]>, Eric Rosen wr
> packet  carry addressing  information  which  is to  be  interpreted in  the

Eric,

I think the use of 127.0.0.1 is a good idea, however, I don't think
the use of 127.x.y.z to test ECMP is a good idea.  I am not objecting
to use of 127/8, just the way ECMP is proposed to be handled.

In the simple case, the ingress puts on one label or a small label
stack.  That ingress may take traffic and spread it over more than one
LSP, but then the label stack is different.  Even though ECMP is used,
the ingress has more than one LSP to test.

If you step TTL in increments of one, at each MPLS LSP hop TTL will
expire if TTL is being decremented.  That LSR can then provide its
mapping and LSP-ping need the ability for that midpoint LSR to provide
more than one mapping if ECMP is used.

The ingress then needs to know how many mappings there are and how to
get packets into each of the available mappings.  There are two types
of possible mappings at a point that does ECMP, label stack based, and
IP header based.

For label stack based mappings, there will only be one mapping for a
given label stack (although for a given LSP there may be multiple
paths used for different lower labels).  The point is that for a label
stack based ECMP, only one label mapping is returned, the one for the
exact label stack used.  If you want to know all mappings, don't
include a lower label.

For a TE tunnel, there is no branching at midpoints for an LSP.
Therefore there is only one mapping.  The hashing and ECMP occurs 
only at the ingress.

The remaining case is an LDP tunnel that uses IP header based ECMP at
midpoint.  To do this an LSR has to be snooping the traffic for IP
headers and consistently seeing them.  Please lets not go into a
tangient over whether this is a good idea, simply accept that it
happens and MPLS-ping has to deal with it.  In this case, TTL expires
and the midpoint has to return more than one mapping.  If the spliting
algorithm is proprietary or uses a seeded hash, then the simplest way
to indicate how to get into any one path is for the midpoint to
provide a address within some range, that the ingress can use to get
there.  Even this is problematic since some implementations
periodically reseed the hash with a random number.  To be general, the
ingress would need to provide an acceptable range (such as 127/24 or
127/8) and the midpoint would need to provide an address and a time
duration for which that address will work (indication of when the seed
will be changed).

The only case where a traffic split occurs in a TE midpoint is
proprietary link bundlings which use either label stack or IP header
methods of splitting.  In this case, the bundling is better exposed
for diagnostic capability and the same issues as above hold.

A very minor points I don't know about you but I can ping 127.0.0.1
but not 127.0.0.2 on my BSD boxes (no big deal, just a change).

So I'm still in favor of using 127/8 but think that ECMP could be done
better.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Dec 2002 03:00:16 -0800 (PST)

> So I'm still in favor of using 127/8 but think that ECMP could be done

Any concrete suggestions?

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Dec 2002 13:19:00 -0500

In message <[email-masked]>, Kireeti Kompella 
> Any concrete suggestions?

You must be catching up.  I just made one.  No problem.  Volume has
been high, s/n low, but some signal.

Curtis