Subject: Comments on draft-agarwal-mpls-ttl-00

From: Francis Arts <[email-masked]>
Date: Sun, 11 Mar 2001 13:38:57 +0100

Hello Bora,

Please find included some replies:

1) Section 2.2.

Bora> I believe the text says to check for oTTL > 0/

Francis >> I agree that indeed  the text states 'oTTL > 0'. However, the
following
Francis >> problem situation can occur:
Francis >> *) iTTL == 0 (that is, the TTL of incoming MPLS packet == 0).

Francis >> The oTTL calculated as proposed in the draft results in
Francis >>                   oTTL = iTTL - 1 = value greater than 0
(unless one would
Francis >> assume that the oTTL is a signed 9 bit quantity (most
significant bit = sign
Francis >> bit) but I do not think that this is the intention).
Francis >>
Francis >> Doing in this case a check on oTTL < >  0, will allow the
Francis >> packet go through while it should not have.
Francis >> According to me this situation can be handled correctly by
checking
Francis >> whether iTTL > 1. This check on the iTTL value should only be
done
Francis >> once it has been determined that the packet is routed (as an
IP or
Francis >> MPLS packet) to a next node.

3) Section 2.3.

Bora> We put the word "push" there to clearly differentiate against the
"POP"
Bora> case. Even when you are pushing, you still need to determine the
iTTL so
Bora> that you can determine the TTL for the label that is being pushed.

Francis >> I agree that even when you are pushing, you still need to
calculate the
Francis >> iTTL for the label being pushed.
Francis >> However, I would propose not to put "push" to differentiate
against
Francis >> the "pop" case since the same node can perform a "pop" and
"push"
Francis >> operation at the same time.

Kind regards,

    Francis.

-------------

http://cell.onecall.net/mhonarc/mpls/current/msg00079.html
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on draft-agarwal-mpls-ttl-00

From: Bora Akyol <[email-masked]>

Date: Sat, 3 Mar 2001 21:36:38 -0800 (PST)

cc: [email-masked], [email-masked], [email-masked], Francois Le Faucheur <[email-masked]>, [email-masked], Shahram Davari <[email-masked]>, Bruce Davie <[email-masked]>, [email-masked], Marijke Coenen <[email-masked]>, [email-masked]

In-Reply-To: <[email-masked]>

X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs

On Sat, 3 Mar 2001, Francis Arts wrote:

>
> Puneet,
>
> Please find included some comments to your draft
> draft-agarwal-mpls-ttl-00.
>
> Kind regards,
>
> Francis.
>
> --------------
>
> 1) Section 2.2.
>
> The text states that oTTL = iTTL -1 and that it is checked whether oTTL
> is greater than 0.
>
> However, this does not cover the receipt of an (erroneous) MPLS packet
> with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a
> oTTL value different from 0. So the MPLS packet would still pass the
> oTTL check while it should not have.
>
> Therefore, I propose to check the iTTL, rather than the oTTL:
> * A check is done whether or not the iTTL value is strictly larger than
> 1. This check on the iTTL value should only be done once it has been
> determined that the packet is routed (as an IP or MPLS packet) to a next
> node.

Francis,

I believe the text says to check for oTTL > 0/

>
>
> 2) Section 2.2.
>
> The text states that 'the oTTL check is performed only if an outgoing
> TTL is set to oTTL'.
>
> However, this is inconsistent with the statement in section 2.4 - 3rd
> bullet: "PHP case - The oTTL check should be performed irrespective of
> whether the oTTL is used in any outgoing label / IP header".

This will be fixed in the next version of the draft.

>
>
> 3) Section 2.3.
>
> The text states that '... we are performing a push / swap / PHP, then
> the iTTL is the TTL ...'.

We put the word "push" there to clearly differentiate against the "POP"
case. Even when you are pushing, you still need to determine the iTTL so
that you can determine the TTL for the label that is being pushed.

>
> I propose to remove the 'push' since this is irrelevant for the incoming
> TTL determination; the push is handled in section 2.4 (outgoing TTL
> determination).
>

Follow-Ups:

Comments on draft-agarwal-mpls-ttl-00

From: Ashley Shi <[email-masked]>

References:

Comments on draft-agarwal-mpls-ttl-00

From: Francis Arts <[email-masked]>

Prev by Date:
Standards for IP stats collection? (corrected)

Next by Date:
MPLS traffic engineering query.

Prev by thread:
Comments on draft-agarwal-mpls-ttl-00

Next by thread:
Comments on draft-agarwal-mpls-ttl-00

Index(es):

Date

Thread