RE: tuneltrace

[Ron Bonica <rbonica@mci.net>]

Danny,

Thanks for your comments. As per our private email exchange, I am posting my
response to the list.

Response follows ....

                               Happy Holidays,
                                 Ron

> -----Original Message-----
> From: danny@sofos.tcb.net [mailto:danny@sofos.tcb.net]On Behalf Of Danny
> McPherson
> Sent: Wednesday, December 20, 2000 3:15 PM
> To: rbonica@mci.net; kireeti@juniper.net; dmm@cisco.com
> Subject: tuneltrace
>
>
>
> A few minor comments:
>
> Section 4, the IETF also supports L2TP, which should be
> specified in the document.

Agreed. Will add it to the next version of the draft.



>
> Section 5, doesn't loose source trace allow you to do
> third party traces, or am I missing something?

You have a point. I will strike the last two paragraphs
from section five, but replace them with two paragraphs that
point out the problems that loose source routing introduce.

Will also add a new protocol requirement that prevents us from
using loose source route, strict source route, or record route
IP Options in our protocol design.



>
> Section 6, there's no wording regarding asymmetry, which
> is a large problem with traceroute today.

Please expand.....



>
> Section 6, item 3 is insufficiently vague.  Is this an
> operator configurable option, or?

User configurable. Will add some words to that effect
in the next version of the draft.



>
> Section 6, item 4, what tunnel components?

Devices that are part of the tunnel (e.g., routers, lsr's).



>
> Section 6, item 5, what details?  And shouldn't the
> service provider have some control over this?

See Section 6.6


>
> Section 6, item 6:  Eh?  What's the purpose of the
> token, so that NMSs and other 'trusted' hosts can
> perform additional functions?  Do you then need to
> define an entire AAA model around this so that NOCs
> have more privileges than customers, customers more
> than peers, etc..?

If the service provider wants to reveal tunnel details
to some, but withhold them from others, his/her network elements
can authenticate each request. If the authentication object
has "the right stuff" in it, the requestor gets tunnel
details. If not, the requestor does not get tunnel details.

The authentication object can be very simple
or very complex. We will probably end up supporting
many kinds of authentication (e.g., none, plain-text
password, MD5, and so on).

>
> Section 6, item 7 should include L2TP.

Agreed.



>
> Section 6, item 8 seems insufficiently vague.

I ask your indulgence on this one. Although it is a bit
vague, it conveys a major design goal. That goal is to
design something that is extensible.



>
> Section 6, item 9, are you suggesting that the
> message be handled in hardware??

This isn't a hardware/software distinction.  It is a distinction
between the control and user planes. Since this is a debugging application,
I want it to tell me about the path through which packets are actually being
forwarded, not the path through which the signaling protocol thinks packets
are being forwarded.

>
> Section 6, item 10, is this not a huge layer violation?

Not necessarily. Although we could design a protocol that fulfills
this requirement by committing layer violations, we could also
design a protocol that fulfills this requirement without commiting
layer violations.

Let's watch for this during the protocol specification phase.

>
> Section 6, item 11, wouldn't this be dependent on
> availability of a return path?

Yes, but the path need not be through a tunnel. Furthermore,
it only needs to be a path to the head end of the tunnel.

>
> Section 6, item 12, isn't this covered by the current
> traceroute, which is specified as required earlier (i.e.
> via TTL)?  Also, don't you mean forwarding loop?

I will strike this requirement in the next version of the
draft. The next requirement (maximum hops) covers the intent.

>
> Section 6, item 13, so you mean terminate as gracefully
> here as in item 12?  What if the forwarding loop is
> intentional and hard-coded via LSPs, PVCs, whatever?
> IMO, a TTLish model is sufficient, or employing some
> max hop count.  What'd you have in mind?

See above.

>
> Section 7, first paragraph:  Are you suggesting AAA
> here, I think you'll have to!

See response to 6.6


>
> Section 7.1, What's a lower-level hop?  LSR?  How's it
> identified?  ASCII string in response rather than via
> DNS PTR RR?

When tracing through an MPLS LSP, the lower layer hop is an
LSR hop. When tracing through an IP-in-IP tunnel, the lower layer
hop is an IP hop.

The tunnel identifier is available for some tunneling technologies,
but not for others. For example, when tracing through an MPLS LSP,
the identifier is an LSP name. When tracing through an IP-in-IP tunnel,
there is no identifier.

>
> Section 7, Perhaps something to indicate the bi-directional
> information of the path is in order (i.e. the path to the
> target, as well as back tot he head-end, as they may very
> well be different)?

Can we infer this from the "type"?

>
> Section 8, IMO, the answer to the last question is YES.
>
>
>
>