Subject: RE: New TTL Draft

From: Puneet Agarwal <[email-masked]>
Date: Fri, 23 Feb 2001 13:53:14 -0800

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: Eric Gray <[email-masked]>
Date: Fri, 23 Feb 2001 19:25:17 -0500

Puneet,

    Thanks for the reply.  One or two comments below...

You wrote:

>  [...]
> 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.

Okay.

> [...]

This would address the case where you are just
addressing the disparity between DS usage and
TTL.  But what about the more general case -
i.e. - where DS is not involved?

The answer that how the PH knows this is out
of scope, might be good enough, but I would like
to know what people are thinking.  I am not sure
that configuration makes sense since it is not
necessarily clear in every case which LSRs are
going to end up being the penultimate hop for
which LSPs.  It really doesn't make a lot of
sense to punt the issue if the current answer
to the question "how could we make it work?" is
"magic"...

> [...]

--
Eric Gray