RE: draft-bonica-tunproto-04.txt

[Ron Bonica <Ronald.P.Bonica@wcom.com>]

Adrian,

Thanks for your comments. Response inline....

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, March 18, 2003 3:06 AM
> To: Ron Bonica
> Cc: ccamp@ops.ietf.org
> Subject: draft-bonica-tunproto-04.txt
>
>
> Hi Ron,
>
> Some thoughts on re-reading this draft...
>
> I think the draft is long enough to need a contents table.

Will do.

>
> Although the access control function is mandatory, why is the
> Access Control
> Object mandatory on a traceProbe? If the requester has nothing to
> say and the
> reporter is happy with that, why force the object to be present?

Good idea. I will change that in the draft

>
> It wasn't clear to me until reading the section on head-end
> object timestamps
> that the traceResponse is routed back through the head of the
> tunnel. Doesn't
> this assume that you have a bidirectional tunnel?

No. It assumes only that all devices that participate in a tunnel
maintain an IP route to the tunnel's head-end.

 Apart from the
> round-trip time
> function, why wouldn't you send the traceResponse back to the
> source by a more
> direct route?

I don't want to require devices that support the tunnel interior
to maintain an IP route to the device that hosts the route-tracing
application. This is of particular concern for tunnels that support
RFC 2547 VPNs.


>
> Isn't there a problem with the TTL method of finding the next
> hop? The path of
> the tunnel may change from one probe to the next giving the
> appearance of loops
> (gaps are less important). You either need to describe apparent
> loops and how to
> prune them, or you need to use another hop identification mechanism.
>

Good point. Traditional traceroute [RFC 2151] deals with this problem by
probing each hop N times (default = 3). If the same node answers each
probe, there is no problem. If the application receives responses from
more than one node, it reports this and the user is aware that something
funny is going on.

GTTP should probably do the same thing. I will add a section describing
the problem and the proposed solution.

> Why is the Access Control Object present on the traceResponse?

Now that I think of it, it really isn't required. I will remove it.

I put it in the traceResponse to protect VPN devices from spoofed
traceResponses that originated outside of the VPN. However, we can
achieve the same thing with the Context Object.

>
> Format diagrams - all the bit counts need to right-shift by one.

Oops. I'll fix that.
>
> Is the ordering of objects in messages mandatory, suggested, optional?

Optional. I will be more specific about that.

>
> Was there a protocol version 0?

No. I guess we could call this version 0.

>
> Lengths. Message lengths appear to be inclusive, object lengths exclusive.
> Consistency would be nice. When you describe the individual
> objects the length
> values you give are actually inclusive. Note also that object
> lengths refer to a
> count of 32-bit words that follow, but are often (never?) the
> last byte in a
> 32-bit word.

I will fix this.

>
> Errors. For unknown, malformed and missing objects it is nice to
> be able to
> indicate the object type that is in error.

We can fix by adding a new field that contains the identifier of the object
that has a problem.

Note also, that if the error is
> missing object, it may not be possible to correctly format a TraceResponse
> Message.

Agreed.

>
> Addresses here are only IPv4. Would it be worth including IPv6 variants?

Let's get some experience with IPv4 and add IPv6 objects later.

>
> Need an error code for IP Header and Tunnel Object both present?

Good point.
>
> 5.2.7 missing description of hop count

Good catch.

>
> Need error needed for hop count flag set and responder address present?

Another good catch! I will add another error code.

>
> Several places say "can be 0 padded for word alignment". I think
> this should
> read "MUST".

Yes.

>
> 5.2.11 Support for unnumbered interfaces?

We should make this work exactly like traditional traceroute. I will add
some words to that effect.

>
> 5.2.12 Flags field. Which bit is bit 0? Compare Propagation
> Object where you say
> "right-most bit".

I will fix this.

>
> Tunnel type.  GRE?

I will fix this too.
>
> I think the security section needs some oomph!

Any suggestions? I am looking for input.

                    Ron

>
> Cheers,
> Adrian
>
>
>