Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Mon, 9 Dec 2002 11:29:21 -0800

> > 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 packet
and will respond accordingly. So the ingress may see an additional TTL expire,
which is not harmful at all.

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:

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 bits of the IP address. And also you need to scan through 16 million addresses in order
to make sure you exercise all the ECMP paths.

> 
> > 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.
My proposal does not support ECMP, but the current proposal, does not  
support ECMP in all implementations either. 
My proposal, does not require any configuration of the IP filters in all
LSRs, which is required by current proposal.
My proposal does not force us to justify the SHOULD NOT part of standard RFCs.

-Shahram

> 
> > Ok., let me make it clear: I want LSP-ping to be improved.
> 
> Great.  So drop the RFC1700 nonsense and lets move on.
> 
> Curtis
>

---

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

In message <[email-masked]
>, Shahram Davari writes:
> 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

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.

> then you are correct, my proposal will not be able to exercise the

I was talking about reality where both MPLS based and IP header based
load spliting occurs.  You have to handle both.

> 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

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.

> My proposal works fine at the intended or unintended egress.

No it doesn't see above.

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

> 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