Subject: feedback on GTTP: draft-ietf-ccamp-tunproto-00

From: "Richard Rabbat" <[email-masked]>
Date: Mon, 23 Aug 2004 14:51:09 -0700

Hi Ron,
I just finished reading the draft and I have some feedback. Some of it
editorial + a few questions. Here goes. I hope this helps move this forward.
Richard.
--
P.2.
-   MPLS LSP as well as they can trace through an IP-in-IP tunnel.
+   MPLS LSP as well as trace through an IP-in-IP tunnel.
 
P.3.
 
-   This section describes the generic route-tracing problem and provides

+   Section 1 describes the generic route-tracing problem and provides

-   tunnels that support the trace path.

+   tunnels that support the traced path.

P. 4.

replace:

              --

             |D0|

              --

              |  -  H1  -                  H2                   -  H3  -

         (IP)  -|D|----|D|-------------------------------------|D|----|D|

                |1|    |2| H2:1  -        H2:2         -  H2:3 |3|    |4|

         (IP)   | |    | |------|D|-------------------|D|------| |    | |

                 -      -       |5| H2:2:1  -  H2:2:2 |6|       -      -

         (MPLS)                 | |--------|D|--------| |

                                 -         |7|         -

                                            -

With:

             +--+

             |D0|

             +--+

              | +-+ H1 +-+                 H2                  +-+ H3 +-+

         (IP) +-|D|----|D|-------------------------------------|D|----|D|

                |1|    |2| H2:1 +-+       H2:2        +-+ H2:3 |3|    |4|

         (IP)   +-+    | |------|D|-------------------|D|------| |    +-+

                       +-+      |5| H2:2:1 +-+ H2:2:2 |6|      +-+    

         (MPLS)                 | |--------|D|--------| |

                                +-+        |7|        +-+

                                           +-+

-   route-tracing application must trace the route between the D1 and D4.

+   route-tracing application must trace the route between the devices D1
and D4.

-   H1, H2 and H3. An IP-in-IP tunnel supports H2. The IP-in-IP tunnel

+   H1, H2 and H3. No tunnel supports H1 or H3. An IP-in-IP tunnel supports
H2. The IP-in-IP tunnel

-   application provides these values and uses them to match traceProbes

-   with traceResponses.

However, the timestamps are not used for matching, so suggestion to change:

+   application provides these values and uses the timestamps to match
traceProbes

+   with traceResponses.

P. 5.

-   The Context Object identifies a VPN context. See Section Section 1.5

+   The Context Object identifies a VPN context. See Section 1.5

P. 6.

-   for Context Object details.

+   for details on Context Object processing and Section 2.2.16 for format
details.

-   The Source, Head-end and Context Objects are described above.

But the Context Object is not described above.

+   The Source, Head-end are described above.

-      contained by an datagram whose TTL expired at the responding

+      contained by a datagram whose TTL expired at the responding

You say:

>   The traceResponse message MUST include an Arrival Object if it

>   describes any interface other than the origination point of a traced

>   path or tunnel.

Is an Arrival Object included or not otherwise? (MAY, MUST NOT, etc.)

P. 7.

-   If traced path does not terminate on the responding device and the

+   If a traced path does not terminate on the responding device and the

-   traceResponse message MUST contain a Next-hp Object. Otherwise, the

+   traceResponse message MUST contain a Next-hop Object. Otherwise, the

-   identical Context Object. See Section Section 1.5 for details.

+   identical Context Object. See Section 1.5 for details.

P. 8.

1.4.1.

1. There is no description of timeout procedures. 

2. What are the timestamps originally? All 0's?

-

   Object. If D1 does not grant access, it sends D0 a traceResponse

   indicating that access has been denied. If D1 grants access...

Is this gttp_access_denied of page 18?

P. 9.

Are there any concerns with the number of ICMP Time Expired messages?

You say:

>   that access has been denied. (D1 would relay this message to D0.)...

Is this relaying done using just forwarding?

Do we need to decrement hop count anywhere? I don't see that.

P. 10.

You say:

>  D0 repeats the process described above in order to discover the

>  balance of the top-level path.

What do you mean by "balance"?

P. 13

-   Source Object many not uniquely identify the route-tracing

+   Source Object may not uniquely identify the route-tracing

1.6 and 1.7

It seems that to detect transient changes is harder than the typical
traceroute application since transient changes may affect some tunnels but
not others in the hierarchy. Is that correct? Is there a best practice about
this issue?

P. 15

-2.2 MessageFormats

+2.2 Message Formats

P. 18

>      6 - gttp_malformed_object

Do we need a gttp_no_response or do we deal with it at the application
layer?

P. 19-31:

Those are not messages, but the objects. I suggest to put 2.2.3 to 2.2.13 in
separate section 2.3.1 to 2.3.11 under:

2.3 Object Formats

   The following subsections detail GTTP object formats

2.3.1 The Source Object

...

This also has the side effect of aligning the paragraph number with the type
field.

P. 19

-   route-tracing application is awaiting a traceResponse.

+   route-tracing application is listening for a traceResponse.

P. 20

-   device received the traceProbe. It represents the number milliseconds

+   device received the traceProbe. It represents the number of milliseconds

P. 22

-   The IP Header and Tunnel Objects are described in dedicated sections

+   The IP Header and Tunnel Objects are described in sections 2.2.10 and
2.2.12

P. 24

>   and contain a valid IPv4 address.

This is the first time in the whole document that GTTP is said to only apply
for IPv4. Am I correct? Should it be mentioned earlier in the abstract or
introduction? Other IP addresses are not mentioned as IPv4 and need to be
explicitly mentioned.

General question:

Introduction is a copy of the abstract. I suggest changing the abstract to
motivate and state what the draft proposes only.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Aug 2004 14:43:16 -0400

Richard,
 
Thanks for these comments. I have addressed them and sent an updated version
of the draft to the draft editor.
 
                                                               Ron

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]] 
Sent: Monday, August 23, 2004 5:51 PM
To: 'Ronald Bonica'; [email-masked]
Cc: 'Richard Rabbat'
Subject: feedback on GTTP: draft-ietf-ccamp-tunproto-00

Hi Ron,