Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Fri, 6 Dec 2002 13:03:36 -0800

Curtis,

Could we add a text to the draft that says, all LSRs must be configured to not drop 127/8 addresses.

Yours,
-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 3:57 PM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <[email-masked]
> >, Shahram Davari writes:
> > More proof:
> > 
> > RFC 1812 (Requirements for IP Version 4 Routers):
> > 
> >   
> >    A router SHOULD NOT forward any packet that has an invalid IP
> >    destination address or a destination address on network 
> 0.  A router
> >    SHOULD NOT forward, except over a loopback interface, 
> any packet that
> >    has a destination address on network 127.  A router MAY 
> have a switch
> >    that allows the network manager to disable these checks. 
>  If such a
> >    switch is provided, it MUST default to performing the checks...
> > 
> >    A router SHOULD provide a mechanism to filter out 
> obviously invalid
> >    routes (such as those for net 127).
> > 
> > -Shahram
> 
> 
> We are not propogating a route.  If a router advertises reachability
> to 127/8 or any more specific route under 127/8 THE ROUTE should be
> rejected.
> 
>   A router SHOULD NOT forward, except over a loopback interface, any
>   packet that has a destination address on network 127.
> 
> This packet is tunneled to a router and then it being sent to the
> local loopback interface.  This is exactly the case that this entry
> says is OK.
> 
> It doesn't matter if the packet arrives in a source routed packet or
> arrives in an MPLS-ping packet.
> 
> Further, even if you interpret this as an invalid usage, the next
> sentence says:
> 
>   A router MAY have a switch that allows the network manager to
>   disable these checks.
> 
> We clearly conform to the spirit of the RFCs describing what to do
> with 127/8.
> 
> Any way you look at it, we also conform to the letter of this
> particular entry.
> 
> You have no valid point to make so I'm dropping off this thread.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 06 Dec 2002 17:02:10 -0500

In message <[email-masked]
> Could we add a text to the draft that says, all LSRs must be configured to no

We don't need to add anything because it is not suggested that you
should drop in RFC1812.  You should do exactly the same thing that you
would do after processing the source route IP option, deliver the
packet to the local loopback interface.

Maybe one of the authors can join (do they really want to?) and say
whether they would see fit to add a sentence or deem it too obvious.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Dec 2002 02:40:17 -0800 (PST)

Hi Curtis,

On Fri, 6 Dec 2002, Curtis Villamizar wrote:

> Maybe one of the authors can join (do they really want to?)

Not really :-)

> whether they would see fit to add a sentence or deem it too obvious.

Saying what?  "Setting the destination IP address to something from 127/8
causes some to break out in a rash, but is perfectly valid"?

Kireeti.

---

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

In message <[email-masked]>, Kireeti Kompella 
> > Maybe one of the authors can join (do they really want to?)

Smart move.

> causes some to break out in a rash, but is perfectly valid"?

I'll take that as closer to a "no its too obvious".  My first choice
as well.

If there remains insistence on the list that we justify the choice of
127/8, the criteria would be:

   An ideal destination address would be deliverable to the local LSR
   when TTL expires, regardless of where in the topology that router
   was.  This first requirement is so that an address on the next
   MPLS-ping capable downstream LSR need not be known to get a
   response.  An ideal destination address would be deliverable within
   an MPLS LSP but otherwise unrouteable even in networks using the
   IANA designated private address space [RFC1700].  This second
   requirement insures that the MPLS-ping packet is not forwarded by
   IP and does not travel further than the LSR where TTL expires, or
   the egress LSR.

   The address space 127/8 is explicitly chosen by IANA to be used
   only to reach the local loopback device on a host or router
   [RFC1812].  This address space is never routeable.  For these
   reasons, destination addresses are chosen from the address range
   127/8.  Multipath capabilities on some routers, are based on a hash
   or other algorithm applied to IP source and IP destination
   addresses [RFC2991].  In order to exercise multipath, addresses
   from a range of addresses must be used.

   An MPLS-ping capable LSR as an LSP egress must be able to deliver
   packets exiting the LSP with an address anywhere in the range 127/8
   and a UDP payload with destination port 3503 to a local loopback
   device.  An MPLS-ping capable LSR as an LSP midpoint must be able
   to deliver packets for which TTL expires which have an IP payload
   and a destination address anywhere in the range 127/8 and a UDP
   payload with destination port 3503 to a local loopback device.

Maybe I should have suggested text in the first place.

Now we have two questions...  First do you agree with the text.
Second is do we need it.

Curtis

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 13 Dec 2002 15:59:28 -0500

Kireeti et al,
It looks like separating the issues may be useful, for e.g. something along the
line:

For "ping" mode:
1) send a labeled test pkt on a p2p LSP
2) send a labeled test pkt on a p2p LSP, with PHP (no label after PHP)
3) send a labeled test pkt  on a mp2p LSP (with and without ECMP)
4) send a labeled test pkt on a mp2p LSP, with PHP (with and without ECMP)
5) FRR case, etc...

Similarly for "traceroute" mode.

This may not be the best/correct/complete way to separate the issues, if so pls
suggest other ways. But I think separating the issues may help in progressing the
draft in the WG. One may find that it may not be necessary to use 127/8, or that
the problem could be partitioned.  Just a thought ...

thanks,
cheng-yin

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 09:48:04 -0500

> the problem could be partitioned.  Just a thought ...

MP is not specific to p2mp.  MP applies to p2p as well.  *Any* LSP may
take a hop which splits traffic and merges it again.  The LSR that
does the split must be able to determine that a specific LSP 1) only
carries IP and can be split based on IP headers, 2) has a label stack
and can be split on labels, 3) can't be split.

Curtis