Subject: RE: Last call on LSP Ping

From: "David Allan" <[email-masked]>
Date: Sun, 8 Dec 2002 11:50:44 -0500

Curtis:

Your tone suggests that you think this document is ready for publication,
and the objections that have been raised are purely designed to obstruct
progress, is this true?

cheers
Dave

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Saturday, December 07, 2002 6:52 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last call on LSP Ping 

In message
<[email-masked]
host.net>, [email-masked] writes:
> > > George....I think the point Shahram was making it is not 
> > even allowed
> > > outside the host/source box according to the text quoted 
> > from the RFcs
> > > below.  Wrapping it in some other package (any, not just 
> > MPLS) is still
> > > violating this requirement...and note that it *must* be 
> > placed in some
> > > package to get across any tranmission medium....IP pkts 
> > don't go raw on
> > > wires.
> > 
> > As far as I'm concerned it is within the spirit of the RFCs.  If you
> > want to insist on the letter of the law, perhaps you should look into
> > a career as a solicitor.
> > 
> > ...George
> 
> George, I am asking a serious question here and I would have appreciated a
> serious answer please.  I'd also like to see some responses to the other
> issues that have been raised.  My experience to date suggests one only
gets
> responses 'when it suits'.  At least others (esp Erics R and G and Curtis)
> have attempted to provide reasoned answers.
> 
> This stuff is going to get delivered whatever right?....so I want to be
sure
> that its as fit for purpose as possible (and that's more than this
> particular 127/8 point).

A lot of packets from my site (here at home) go through the Internet,
all destined to a subnet of 10/8 (in the office).  This (10/8) is also
not a routeable address covered in the same sections as 127/8 in
RFC1700 and RFC1812.  Its OK to deliver these packets since they are
encapsulated in something else.  It is not considered a violation of
RFC1700 or RFC1812 to forward these across the Internet where 10/8 and
127/8 are considered to be "martian packets".

Going way back to 1992, the mbone tunnels were originally built out of
source routed tunnels with a multicast destination.  They later
switched to a tunnelled encapsulation due to performance problems of
certain routers when handling large volumes of source routed packets.
This was not considered a violation of RFC1700 or RFC1812.

There are plenty of precedences for using private addresses inside
something else.

In many circumstances, packets with private addresses are tunneled.
You have to separately look at what happens at the end of the tunnel
after the encapsulation is stripped off.

> Here's my understanding of the current position on this specific point:
> 
> There are (at least) 2 possible cases:
> 1	127/8 addressed pkts should never leave a box
> 2	127/8 can always leave a box.....since I can put 127/8 addressed
> pkts in ATM or FR (or ethernet?) directly.....I see no significant
technical
> difference here to the MPLS case that is argued as being justified.
> [Aside - one could generalise the above case 2 to *any* IP addressed
packet,
> or we could make 127/8 a special case]

127/8 cannot be forwarded based on the 127/8 destination.  Just as
traffic from 10/8 can leave a subnet, croos the big-I Internet, and
reenter a subnet of 10/8, so can a packet be formed with a 127/8
destination and be encapsulated in something and sent.

What happens when the outside encapsulation is stripped off also has
to be examined.

When the labels are gone, the 127/8 remains and the packet is sent to
the loopback address.  That is the one exception allowed by RFC1812
and delivery to the loopback is the explicit intended use of 127/8.

> Now I just want a ruling that 2 is fine (perhaps as a special case?), and
as
> long as its agreed now then that's OK....I don't want this raised by
someone
> X months hence after this stuff is being shipped and operators have
deployed
> it.

If you had a legitimate reason to deliver traffic to the loopback
device on the other end of a FR or ATM link, then putting 127.0.0.1 in
the destination and a valid UDP payload with a port number for that
application, then it would be fine.

There is a legitimate reason for selecting a 127/8 address for this
application.  Because it is used for a diagnostic we DON"T want it to
be routeable.  RFC1700 and RFC1812 guarentee that it won't be
routeable.  RFC1700 and RFC1812 explicitly set this address space
aside for use with the loopback device.

> regards, Neil

Once again, I think the MPLS-ping objectors are simply grasping at
straws.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 08 Dec 2002 14:34:12 -0500

In message <[email-masked]>, "
David Allan" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C29ED9.A290A81A
> Content-Type: text/plain
> 
> Curtis:
> 

Dave,

Since you asked, yes I do think the comments by two or more
individuals are more obstructionist than constructive, but it seems
particularly clear in this issue.

As far as whether the document is ready to publish, I think the
document could stand a great deal of improvement in clarity, most in
explaining how the mechanisms are intended to be used.  There is no
doubt the wording in many places can stand much improvement but the
intent to me seems clear enough (with only minor exceptions) and I
feel I could implement from it.

The capability is needed and the cost of providing it are minimal,
most important they don't impact existing hardware.  Given only two
simple prerequisites, implementing MPLS-ping is simply a matter of
application code.  The prerequisites are 1) the ability to inject
packets (from the ingress LSR) directly into an MPLS LSP, and 2) the
ability to strip off labels and deliver a 127.0.0.1 addressed packet
to the loopback.  The former is easy enough to add and needed on the
LSR for other reasons.  The latter simply involves insuring that the
LSR does not engage in overzealous filtering.  All filters should be
configurable so this should not be a problem for any existing LSR.

That is not to say that no legitimate issues have been brought up.
For example: 1) it is not clear to me how to handle IP src/dst hash
based or MPLS label hash based load balancing, as would occur in
LDP/ECMP, 2) I'm not clear on the usage of the FEC stack.  I think 1)
may be a deficiency, 2) is either a clarity or a feature with no clear
purpose.  Perhaps an example (sent to the list if not in the document)
would clear up the purpose of FEC stack.

If the dialog were constructive, we'd be trying our best to see the
intended use (and I'm not finding that overly difficult) and where it
is not clear, asking the author to provide clarification.  We wouldn't
be acting like a bunch of lawyers trying to stall by making arguments
over technicalities where the arguments have very weak if any basis.

Perhaps we should do what was done in IDR for bgp4-17 and list the
objections and try to gain consensus on each individually.  This way
if the general feeling is that an objection does not have merit, the
issue is resolved as having consensus with possibly one or a very
small number of discenting opinions.  Looking over the past mail (I
think I've saved most or all of it), there are not that many issues
though you have to wade through some diatribe.  All of the comments do
deserve a response.  Kireeti, Ping Pan, and the other authors may have
to make time for this.

Curtis

ps - sorry - this is close to technical content free but answering a
direct question - now back to the topic of whether the 127/8 issue has
any merit (which hopefully won't go on much longer).