The MPLS WG Archive

[Puneet Agarwal <puneet@pluris.com>]

Eric,

Comments inline.

>-----Original Message-----
>From: Eric Gray [mailto:eric.gray@sandburst.com]
>Sent: Friday, February 23, 2001 9:34 AM
>To: Bora Akyol
>Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash);
>'mpls@uu.net'
>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
>