Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Mon, 9 Dec 2002 13:46:49 -0800

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

This is what RFC1812 says:

   A router MUST NOT discard a datagram just because it was received
   with TTL equal to zero or one; if it is to the router and otherwise
   valid, the router MUST attempt to receive it.

I agree that if LSP-pings ends up in a router that it was not intended
it will get discarded. However, I am wondering what is the required behavior
in LSP-ping draft? Is it to get a reply even from an egress LSR that is not
the correct egress? If so then how can that egress use the RSVP return path
to respond?

I think not receiving a reply from a wrong egress should be fine, because
it gives you an LSP-ping failure. And then you could run trace-route, to figure out
the exact path.

>Plus if the control plane is not IP, a case that some people
> insisted had to be supported, then that ICMP packet goes nowhere.

I didn't know that LSP-ping works without IP in the control plane. Besides I am not using ICMP to detect ping failure, just not receiving ping reply, would indicate the LSP failure.

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

But isn't this what the draft currently proposes: "the destination IP address is a (randomly chosen) address from 127/8" ?

-Shahram

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

---

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

In message <[email-masked]
>, Shahram Davari writes:

That is the case 1 I had listed as a deficiency to your suggestion.
So you agree case 1 is valid.

If packets were misdirected, then there has to be an RSVP return path
for a TE tunnel and LDP requires that their be IP routes.  If there
are no IP routes then normal TTL ICMP goes nowhere.

> it gives you an LSP-ping failure. And then you could run trace-route, to figu

As you increment TTL on the outer label, for LDP you don't know the
loopback address (or any address) of the routers.  There would be no
way to get information from these intermediate routers.

> I didn't know that LSP-ping works without IP in the control plane. Besides I 
> am not using ICMP to detect ping failure, just not receiving ping reply, woul
> d indicate the LSP failure.

I thought that was the purpose of delivery through the RSVP return
path for the case where essentially static TE tunnels were used
(configured by the NMS) or IP is not trusted.  I don't like this but
somehow I thought that was the purpose.

   [...] An MPLS echo request would normally have "Reply via an IPv4
   UDP packet"; if the normal IPv4 return path is deemed unreliable,
   one may use "Reply via an IPv4 UDP packet with Router Alert" (note
   that this requires that all intermediate routers understand and
   know how to forward MPLS echo replies) or "Reply via the control
   plane" (this is currently only defined for control plane that uses
   RSVP).

> But isn't this what the draft currently proposes: "the destination IP address
>  is a (randomly chosen) address from 127/8" ?
> 
> -Shahram

And if you were paying attention you would have noted that I have
repeatedly stated that the means to handle ECMP is deficient.

I haven't come up with a complete solution but at least I've managed
more than a one sentence "proposal" that won't support ECMP at all.

Curtis