Subject: RE: Last call on LSP Ping

From: "Gray, Eric" <[email-masked]>
Date: Mon, 9 Dec 2002 13:42:29 -0500

I also would think this better if it specifically said
use 127.0.0.1 as opposed to what it currently says.

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

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, December 09, 2002 1:33 PM
> To: [email-masked]
> Cc: Gray, Eric; [email-masked]'; [email-masked]
> Subject: Re: Last call on LSP Ping
> 
> 
> In message <[email-masked]>, Eric
> Rosen wr
> ites:
> >
> > 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.
> 
> 
> 
> 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: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Dec 2002 14:05:08 -0500

In message <[email-masked]
> use 127.0.0.1 as opposed to what it currently says.

What's the solution for ECMP then?

Note that even below, if a second branch point is hit, then you need a
set of addresses that falls into the first hash but are spread out
among the second hash.

Like I said a few messages back, I don't know that enough thought has
been put into ECMP.

Curtis