Subject: RE: New TTL Draft

From: Shahram Davari <[email-masked]>
Date: Mon, 26 Feb 2001 13:03:20 -0800

Hi Puneet/Eric,

1)You are right we have not described how to signal Pipe/short pipe/uniform models. Since our draft is in its last call and can't be changed substantially, I propose that we get together to write a separate I-D to address the CR-LDP/RSVP-TE extensions for signaling the tunneling model.

2) Section 2.4 does not discuss an important case that is: egress processing of tunnels, i.e. pop and forwarding the packet as MPLS. 

3)As you may know, version -08 of our draft has introduced two types of Pipe tunnels a) Short pipe and b) Pipe. The short pipe is what was called the "pipe" in version -07. But the new "pipe" model is a bit different, in the sense that all the egress processing is done based on top label. So your description of TTL processing for the pipe model remains valid for "short pipe" (except that you need to describe the egress processing too, see bullet 2 above), but you need to define another TTL processing rule for the "pipe", which is:  the top label TTL is decremented and checked, while the lower label TTL (unchanged) is used for forwarding the packet. 

Yours,
-Shahram

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Friday, February 23, 2001 4:53 PM
> To: 'Eric Gray'
> Cc: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; Shahram Davari; Bora Akyol
> Subject: RE: New TTL Draft
> 
> 
> Eric,
> 
> Comments inline.
> 
> >-----Original Message-----
> >From: Eric Gray [mailto:[email-masked]]
> >Sent: Friday, February 23, 2001 9:34 AM
> >To: Bora Akyol
> >Cc: [email-masked]; [email-masked]; B, Prakash K (Prakash);
> >[email-masked]'
> >Subject: Re: New TTL Draft
> >
> >
> >Bora/Puneet,
> >
> >    Some comments.
> >
> >    In section 2.4, item 3 - PHP does not necessarily expose an
> >IP header.  The text in this section is not clear in this respect
> >- possibly because of the textual construct "IP-Header/label".
> >It might be somewhat clearer if you use "header" and add a
> >paragraph stating that the PHP exposed header may be either
> >an IP header or an MPLS label and the appropriate oTTL  is
> >written to the corresponding TTL field of this PHP exposed
> >header.
> 
> I agree. We will change the wording in the next rev of the draft. 
> >
> >    Also, in this section, why is oTTL set to the TTL of the
> >exposed header if it is not used for anything?
> 
> Good point. We do not need to set this. This was a leftover 
> from some text
> we took out of section 2.5 at the last moment that used this 
> information. We
> will fix this in the next rev.
> >
> >    In addition, if your actually specifying a behavior (rather than
> >an architecture), I believe you need to allow that the TTL may
> >be decremented by a number other than one.  RFC 791 states
> >that RFC is decremented by at least one.  Your draft states in
> >several places that iTTL is decremented (I assume that the
> >underscore in these cases is meant to be a minus sign) by one.
> 
> The underscore is indeed supposed to be a minus. Will be 
> fixed in the next
> rev.
> I have no problems in allowing the iTTL to be decremented by 
> more than one.
> I will change the text to state that the iTTL should be 
> decremented by "N",
> where "N" is user configured and is greater than 0. The 
> default value of "N"
> should be 1.
> 
> >
> >    There are practical reasons for decrementing TTL by more
> >than one (a high-cost or low-bandwidth link, for example)
> >when it is desirable to accelerate the aging of possibly looping
> >packets.  A higher TTL decrement punishes all packets that use
> >the link, but it punishes looping packets much more.
> >
> >    Finally, what is the mechanism which the PHP uses to determine
> >whether or not the LSP is using the pipe or the uniform model?  I am
> >not sure this information is currently available.
> 
> You may be right. I looked through 
> "draft-ietf-mpls-diff-ext-08.txt", but
> did not see any method to signal the model (pipe or uniform) 
> associated with
> the LSP, using either RSVP or LDP. If it is a missing piece, 
> then I hope
> that it will be addressed by the authors of that draft.
> 
> -Puneet
> 
> >
> >--
> >Eric Gray
> >
> >Bora Akyol wrote:
> >
> >> Note that we (Puneet and I) just posted an Internet Draft on TTL
> >> handling in hierarchical MPLS networks.
> >>
> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt
> >>
> >> 
> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt
> >>
> >> We welcome any comments,
> >>
> >> Bora Akyol
> >
>

---

From: Puneet Agarwal <[email-masked]>
Date: Mon, 26 Feb 2001 15:00:17 -0800

Hi Shahram,

Thanks for your comments. My comments are inline.

-Puneet

>
>Hi Puneet/Eric,
>
>1)You are right we have not described how to signal Pipe/short 
>pipe/uniform models. Since our draft is in its last call and 
>can't be changed substantially, I propose that we get together 
>to write a separate I-D to address the CR-LDP/RSVP-TE 
>extensions for signaling the tunneling model.

Agreed. We can take this up privately with each other.

>
>2) Section 2.4 does not discuss an important case that is: 
>egress processing of tunnels, i.e. pop and forwarding the 
>packet as MPLS. 

Pop (or Egress Pop to distinguish from PHP) is actually covered in section
2.3. The possibly operation when forwarding the packet as MPLS are covered
in the 3 bullets  of section 2.4. Combine section 2.3 and the relevant
section of 2.4 and I think your concern about the missing case should be
answered. Hence as far as I can see the case is convered, but please let me
know if you still think that it is not addressed.
>
>3)As you may know, version -08 of our draft has introduced two 
>types of Pipe tunnels a) Short pipe and b) Pipe. The short 
>pipe is what was called the "pipe" in version -07. But the new 
>"pipe" model is a bit different, in the sense that all the 
>egress processing is done based on top label. So your 
>description of TTL processing for the pipe model remains valid 
>for "short pipe" (except that you need to describe the egress 
>processing too, see bullet 2 above), but you need to define 
>another TTL processing rule for the "pipe", which is:  the top 
>label TTL is decremented and checked, while the lower label 
>TTL (unchanged) is used for forwarding the packet. 

We had based our draft on -07 version of the mpls-diff draft. I will take
into account the -08 version (where the new model nomenclature was
introduced) and update our spec accordingly.

-Puneet

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Feb 2001 11:18:51 -0800

Hi Puneet,

> know if you still think that it is not addressed.

As you know there are at least 2 distinct operations that are needed 
for TTL processing:

1) Determining iTTL
2) Determining oTTL

Section 2.3 describes the iTTL determination for both PHP and non-PHP case.
Section 2.4 however describes the oTTL determination for PHP case only. I 
can't see anywhere in the draft that talks about oTTL determination for non-PHP
case. Do you see any?

Yours,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Feb 2001 12:58:32 -0800

Hi Puneet,

I can't follow your reasoning. Let me explain what I am trying to say:

If an egress router is the terminating point of a pipe/uniform tunnel, then the egress router must pop the top label and forward the packet using the label (or IP header) that is beneath the popped label. My question is: What TTL is encoded in the forwarding label (or IP header). The answer is: oTTL, which is equal to oTTL= iTTL-1, in which iTTL determination depends on the tunnel model and is described in section 2.3.

So my suggestion is to add another bullet (say bullet 4) to section 2.4, that says:

4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). The TTL of the forwarding label (or IP header) is set to:

oTTL = iTTL-1

in which, iTTL is determined based on the type of tunnel (i.e., uniform/pipe) as explained in section 2.3.

Yours,
-Shahram

> Sent: Tuesday, February 27, 2001 3:09 PM
> To: Shahram Davari; 'Eric Gray'
> [email-masked]'; Bora Akyol
> Based on the tunnel mode definitions in the -07 version of 
> mpls-diff draft,
> the oTTL determination is not needed explicitly for the "Pop" 
> case. After
> you perform "Pop" (recursively), you need to route (determine 
> the egress
> interface etc) the exposed header (IP packet or label). You 
> never "Pop" the
> label you route on - you can only SWAP, SWAP+Push or PHP 
> (+Push) the label.
> 
> Hence I never added the bullet for "Pop" when determining 
> oTTL as it is not
> a legal operation. If you want, I can add text in section 2.4 
> of the draft
> that a "Pop" is not a legal operation for a label we route 
> on. Would that
> help?
> 
> Hope this clarifies.
> 
> -Puneet
> 
> >From: Shahram Davari [mailto:[email-masked]]
> >Sent: Tuesday, February 27, 2001 11:19 AM
> >To: 'Puneet Agarwal'; 'Eric Gray'
> >[email-masked]'; Bora Akyol

---

From: Puneet Agarwal <[email-masked]>
Date: Tue, 27 Feb 2001 20:10:45 -0800

Hi Shahram,

As I had briefly mentioned in reply to Eric's earlier email on the Pop
issue, we do not perform a "Route and a Pop" - that is actually treated as a
"Route and a PHP".

To quote from our ttl draft section 2.4:

"For packets that are routed as MPLS, we have three cases"

the semantics of "routed as MPLS" implies that any egress Pops have already
been performed. If you think that this was unclear in the draft then I will
clarify it.

Some more comments inline.

-Puneet
>Sent: Tuesday, February 27, 2001 12:59 PM
>If an egress router is the terminating point of a pipe/uniform 
>tunnel, then the egress router must pop the top label and 
>forward the packet using the label (or IP header) that is 
>beneath the popped label. My question is: What TTL is encoded 
>in the forwarding label (or IP header). The answer is: oTTL, 
>which is equal to oTTL= iTTL-1, in which iTTL determination 
>depends on the tunnel model and is described in section 2.3.
>
>4) Pop : This is the terminating point of an LSP tunnel, in 
>which, first the top label is popped and then the packet is 
>forwarded based on the lower label (or exposed IP header). The 
>TTL of the forwarding label (or IP header) is set to:
>
>oTTL = iTTL-1
>
>in which, iTTL is determined based on the type of tunnel 
>(i.e., uniform/pipe) as explained in section 2.3.

I would be happy to include the text with a few modifications:

4) Pop : This is the terminating point of an LSP tunnel, in 
which, first the top label is popped and then the packet is 
forwarded based on the lower label (or exposed IP header).
Note that this operation can occur recursively. The iTTL is
updated as explained in section 2.3. The outgoing TTL would
be determined by the last non "Pop" operation performed
on the packet.

Would such a text address your concerns?

-Puneet