Subject: Re: Last call on LSP Ping

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Dec 2002 17:14:56 -0500

In message <[email-masked]
>, Shahram Davari writes:
> Curtis,
> 
> Could you please enlighten us on how one can test all the ECMP paths without 
> needing to send 16 million LSP-pings?
> 
> -Shahram

Yes.  Look at the message below (at the very bottom).

I suggested that the midpoint be capable of returning more than one
mapping, one mapping for each ECMP path and an address that can be
used for each.  In a later message I pointed out that this doesn't
work well for multiple branch points.  In a third message I suggested
a way to handle multiple ECMP branch points but it does not fully
exercise the forwarding plane, only the control plane.

Curtis

> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[email-masked]]
> > Sent: Monday, December 09, 2002 3:15 PM
> > To: Shahram Davari
> > Cc: [email-masked]'; David Allan; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: Last call on LSP Ping 
> > 
> > 
> > 
> > In message 
> > <[email-masked]
> > >, Shahram Davari writes:
> > > > > First of all I did propose using the egress IP address and 
> > > > setting the
> > > > > TTL=1 in the IP header. This makes sure that the LSP-ping 
> > > > packet will
> > > > > not get forwarded after the MPLS labels are poped.
> > > > 
> > > > Glad to see this change to a technical discussion.  Took a while.
> > > > 
> > > > This proposal has two flaws, 1) when the label gets POPed and the
> > > > egress isn't the router you thought it should be the 
> > response is an
> > > > ICMP TTL expired, 2) no way to handle ECMP is proposed.
> > > > 
> > > > Please indicate how you would handle ECMP.
> > > 
> > > 
> > > 1)Yes the ICMP TTL expire will be generated and the packet 
> > will be delivered 
> > > to control plane. The control-plane will check and see the 
> > packet being OAM p
> > > acket
> > > and will respond accordingly. So the ingress may see an 
> > additional TTL expire
> > > ,
> > > which is not harmful at all.
> > 
> > Normal delivery of a packet with TTL=1 is to do TTL processing and
> > then drop the packet.  The payload of the packet is not examined to
> > see if it is a service that is recognized for which additional
> > diagnostics could be sent.  Therefore, only a ICMP TTL expired is
> > sent.  Plus if the control plane is not IP, a case that some people
> > insisted had to be supported, then that ICMP packet goes nowhere.
> > 
> > > 2)MY proposal handles the ECMP, if the ECMP algorithm is 
> > only based on MPLS
> > > stack. In case the ECMP algorithm is also based on IP Dest Address,
> > > then you are correct, my proposal will not be able to exercise the
> > > ECMP paths.  But:
> > 
> > I was talking about reality where both MPLS based and IP header based
> > load spliting occurs.  You have to handle both.
> > 
> > > The current proposal may not be able to exercise the ECMP 
> > paths either,
> > > because the hashing algorithm may not necessarily be based 
> > on the first 7 bit
> > > s of the IP address. And also you need to scan through 16 
> > million addresses i
> > > n order
> > > to make sure you exercise all the ECMP paths.
> > 
> > Hash exercises all bits.  Limiting the addressing to one host address
> > makes matters worse.  Randomly trying addresses is not a good way to
> > check for multiple paths.
> > 
> > I sent three message on deficiencies in ECMP handling.  One enumerated
> > some cases.  A second noted the multiple branch points problem.  A
> > third suggested a way around it but noted that this didn't exercise
> > the forwarding plane, only the control plane.
> > 
> > > > > Secondly, it is
> > > > > not my draft, those who have written it should find 
> > > > alternate methods.
> > > > 
> > > > They have proposed something that will work.  You have now made a
> > > > counterproposal.  You need to justify on technical 
> > grounds why not to
> > > > use their proposal, why yours will work, and why yours is better.
> > > 
> > > Here is the justification:
> > > 
> > > My proposal works fine at the intended or unintended egress.
> > 
> > No it doesn't see above.
> > 
> > > My proposal does not support ECMP, but the current 
> > proposal, does not  
> > > support ECMP in all implementations either. 
> > 
> > If it turns out that we need an address range to exercise IP src/dst
> > based hash, then your proposal is unacceptable.
> > 
> > > My proposal, does not require any configuration of the IP 
> > filters in all
> > > LSRs, which is required by current proposal.
> > 
> > Justifying this on the basis that a configuration entry on *some*
> > routers might have to be changed is a very weak justification.
> > 
> > > My proposal does not force us to justify the SHOULD NOT 
> > part of standard RFCs
> > 
> > RFC1812 explicitly states that 127/8 can't be forwarded except to the
> > loopback device.  Therefore the exception is already in place in a
> > standard RFC.  So give up on this already.
> > 
> > > -Shahram
> > 
> > Lets see if there is support for your proposal.
> > 
> > Curtis

Date:    Mon, 09 Dec 2002 13:32:34 EST
To:      [email-masked]
cc:      "Gray, Eric" <[email-masked]>,
	 "[email-masked]'" <[email-masked]>, [email-masked]
From:    Curtis Villamizar <[email-masked]>
Subject: Re: Last call on LSP Ping 
In-reply-to: Your message of "Mon, 09 Dec 2002 11:36:56 EST."
	 <[email-masked]> 

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: Shahram Davari <[email-masked]>
Date: Mon, 9 Dec 2002 12:34:51 -0800

Curtis,

Could you please enlighten us on how one can test all the ECMP paths without needing to send 16 million LSP-pings?

-Shahram