Subject: RE: New revision of the MPLS ttl draft

From: Puneet Agarwal <[email-masked]>
Date: Thu, 11 Oct 2001 13:19:43 -0700

Hi Shahram,

It is entirely possible that I missed something in your argument so please
bear with me.

I do not understand the need for complicated signalling between the service
provider and the customer. In the option (C) that I outlined, the service
provider's egress LSR always decrements by 1 for ALL customers . It is up to
the customer to determine how he wants to take ATM links (per your example)
into account. In (C), the service providers egress LSR *is* doing
deterministic (customer independant) TTL processing.

It is my expectation that realistic deployments would have the providers
egress LSR decrement TTL by 1 just like IP packet TTL is decremented by 1 at
each hop by all  providers (at least I do not know of any exceptions). Just
like there is no IP TTL decrement signalling between providers and
customers, I expect the same to be true for MPLS TTL. Much like for IP,
where a node can decrement the TTL by more than 1 (rfc1812), we leave the
door open for service providers to configure their egress LSRs to decrement
by more than 1.

In fact, having a configurable TTL decrement value was a requirement that
was raised during the previous (-00) draft discussion and hence was added to
the current (-01) draft.

Hope this helps.

-Puneet

>-----Original Message-----
>From: Shahram Davari [mailto:[email-masked]]
>Sent: Thursday, October 11, 2001 6:16 AM
>To: 'Puneet Agarwal'
>Cc: [email-masked]
>Subject: RE: New revision of the MPLS ttl draft
>
>
>Hi Puneet,
>
>I think the flexibility on the TTL decrementing by the egress 
>LSR is something that is not desirable in the scenario that I 
>mentioned. This kind of flexibility requires complicated 
>signaling between service provider and customer in order to 
>inform the provider of the changes in the customer network, as 
>well as a database in the egress LSR to store each customer's 
>requirements. Also the flexibility may lead to 
>interoperability problem.
>
>Therefore I argue that the egress LSR in the pipe model MUST 
>do a deterministic TTL operation (NOT FLEXIBLE), be it a 
>decrement of "0" or "1" or any "n", but for a standard 
>interoperable operation it should not be configurable. 
>
>If flexibility is required the short pipe model could be used.
>
>Yours,
>-Shahram
>
>> -----Original Message-----
>> From: Puneet Agarwal [mailto:[email-masked]]
>> Sent: Wednesday, October 10, 2001 7:41 PM
>> To: Shahram Davari; 'Eric Gray'
>> Cc: Puneet Agarwal; [email-masked]
>> Subject: RE: New revision of the MPLS ttl draft
>> 
>> 
>> Hi Shahram,
>> 
>> Your solution (B) assumes that D (the service provider egress LSR)
>> decrements the TTL by 3. The draft is extremely flexible and 
>> actually allows
>> identical result by considering an alternate solution (C).
>> 
>> (C) Let D subtract by 1 and G subtract by 3. This will give 
>> you identical
>> behaviour and in this case the subtract by 3 knowledge 
>> resides completely in
>> the customers network and the service provider has no 
>knowledge of the
>> customers TTL decrement policy. 
>> 
>> From the service provider's perspective, a packet that enters 
>> their network
>> with TTL n, then is encapsulated in a Pipe Model tunnel (with 
>> TTL n-1),
>> exits their network with TTL n-2 [spec section 4.3](if the 
>> service providers
>> wants to decrement ttl by 1 for each hop internally) for all 
>> customers. The
>> customers can still choose to implement any ttl decrement 
>> policy that is
>> unknown to the service provider. 
>> 
>> Hope this helps and addresses your concern. Hence I do not 
>> see a need to
>> change the draft.
>> 
>> Thanks.
>> 
>> -Puneet
>> 
>> 
>> >-----Original Message-----
>> >From: Shahram Davari [mailto:[email-masked]]
>> >Sent: Wednesday, October 10, 2001 1:30 PM
>> >To: 'Eric Gray'
>> >Cc: 'Puneet Agarwal'; [email-masked]
>> >Subject: RE: New revision of the MPLS ttl draft
>> >
>> >
>> >Hi Eric,
>> >
>> >Because the TTL of the inner LSP belongs to the customer. And 
>> >the customer has a policy of let's say subtracting a value of 
>> >"n" from TTL. Now if the customer does not have control over 
>> >the TTL subtraction, even in a single node, the TTL may get 
>> >expired earlier or later than he expects. Let me give you 
>an example:
>> >
>> >                       
>> > A-------B-----C-----D-----E------F-----G-----H
>> > --------> LSP1----->
>> > -------------------->LSP2------------------->
>> >     TTL = N
>> >
>> >Assume 
>> >1) LSP2 is the inner LSP
>> >2) A, B, C, H and the ingress port of D are POS.
>> >3) The egress port of D is LC-ATM
>> >4) E, F are ATM LSRs
>> >5) The ingress port of G is LC-ATM
>> >6) The egress port of G is POS.
>> >7) A,B,C,D belong to provider X
>> >8) E,F,G,H belong to provider Y
>> >9) TTL=N for LSP2 between A and D
>> >
>> >In theory the TTL received by H must be N-4. However, since E, 
>> >F and ingress of G are ATM, they can't subtract the TTL. 
>> >
>> >There are two solutions:
>> >
>> >A) Let's D do nothing and the customer Y subtract a value of 4 
>> >at the egress port of G, when the packet is sent to H.
>> >B)Let D subtract a value of 3 before sending it to E, and G 
>> >subtract TTL by 1.
>> >
>> >It seems that for Pipe model, the current draft prefers the 
>> >second solution,while I prefer the first one. The reason is 
>> >that by choosing option B, you need to store the value to be 
>> >subtracted from TTL for each individual customer, while in 
>> >method A, it is up to customer to subtract whatever value he wants.
>> >
>> >My argument is that the Short pipe model should fulfill method 
>> >B, and Pipe model should fulfill method A.
>> >
>> >
>> >Yours,
>> >-Shahram
>> >
>> >> -----Original Message-----
>> >> From: Eric Gray [mailto:[email-masked]]
>> >> Sent: Wednesday, October 10, 2001 3:10 PM
>> >> To: Shahram Davari
>> >> Cc: 'Puneet Agarwal'; [email-masked]
>> >> Subject: Re: New revision of the MPLS ttl draft
>> >> 
>> >> 
>> >> Shahram,
>> >> 
>> >>     Can you help me to understand this question?  Why would 
>> >> the customer
>> >> router dwnstream of the egress LSR want (or need) to know 
>> >how much TTL
>> >> has been decremented by the egress LSR?
>> >> 
>> >> You wrote:
>> >> 
>> >> > Hi Puneet,
>> >> >
>> >> > But your draft says that any value other than 1 can be 
>> >> subtracted from TTL. So how does a customer router that sits 
>> >> downstream of the egress LSR know how much has been 
>> >> subtracted from the TTL?
>> >> >
>> >> > Yours,
>> >> > -Shahram
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Puneet Agarwal [mailto:[email-masked]]
>> >> > > Sent: Tuesday, October 09, 2001 11:09 PM
>> >> > > To: Shahram Davari; [email-masked]
>> >> > > Subject: RE: New revision of the MPLS ttl draft
>> >> > >
>> >> > >
>> >> > > Hi Shahram,
>> >> > >
>> >> > > Thanks for your comments.
>> >> > >
>> >> > > Regarding not storing the TTL decrementing policy of the
>> >> > > customer in the
>> >> > > provider's egress LSR(s), I do not think that the proposed
>> >> > > ttl processing
>> >> > > needs/requires the customers ttl decrement policy to be known
>> >> > > to the Egress
>> >> > > LSRs. From a customers perspective, they send a packet with
>> >> > > ttl n and they
>> >> > > get back a packet with ttl n-2. If the customer wants, they
>> >> > > can decrement
>> >> > > the ttl by any amount they want without the providers egress
>> >> > > LSR knowing
>> >> > > anything about it. TTL processing is different (and easier to
>> >> > > determine)
>> >> > > than PHB determination as the TTL field has the same
>> >> > > semantics in either the
>> >> > > providers network or the customers network - which is not
>> >> > > true for the bits
>> >> > > used for PHB determination.
>> >> > >
>> >> > > Hence I do not see a reason to change the TTL decrementing
>> >> > > policy for Pipe
>> >> > > model LSPs. (There are other valid reasons for our proposal
>> >> > > but they are not
>> >> > > relevant to the points you've raised).
>> >> > >
>> >> > > Hope this helps.
>> >> > >
>> >> > > Thanks.
>> >> > >
>> >> > > -Puneet
>> >> > >
>> >> > > >-----Original Message-----
>> >> > > >From: Shahram Davari [mailto:[email-masked]]
>> >> > > >Sent: Tuesday, October 09, 2001 1:34 PM
>> >> > > >To: 'Puneet Agarwal'; [email-masked]
>> >> > > >Subject: RE: New revision of the MPLS ttl draft
>> >> > > >
>> >> > > >
>> >> > > >Hi Puneet,
>> >> > > >
>> >> > > >The reason that Pipe model was introduced was that we didn't
>> >> > > >want to store the customer policies in the egress LSR. This
>> >> > > >meant from the Diffserv perspective, that we didn't want to
>> >> > > >store EXP<=>PHB mapping for each individual 
>customer. The Pipe
>> >> > > >model essentially terminates the tunnel on the ingress line
>> >> > > >card of the Router downstream of the Egress LSR, rather than
>> >> > > >on the egress line-card of the egress LSR.
>> >> > > >
>> >> > > >As mentioned in your draft, each domain may have its own
>> >> > > >policy (value to be decremented) for decrementing the TTL.
>> >> > > >Therefore it seems to me that for the same reason, it is
>> >> > > >better not to store TTL decrementing policy and apply it to
>> >> > > >the packet in the egress LSR for the Pipe model.
>> >> > > >
>> >> > > >Therefore I suggest that the Pipe model TTL processing be the
>> >> > > >same as Short-pipe model with PHP.
>> >> > > >
>> >> > > >Yours,
>> >> > > >-Shahram
>> >> > > >
>> >> > > >> -----Original Message-----
>> >> > > >> From: Puneet Agarwal [mailto:[email-masked]]
>> >> > > >> Sent: Monday, October 08, 2001 5:18 PM
>> >> > > >> To: [email-masked]
>> >> > > >> Subject: New revision of the MPLS ttl draft
>> >> > > >>
>> >> > > >>
>> >> > > >> A new revision of the "TTL Processing in MPLS Networks" has
>> >> > > >> been submitted.
>> >> > > >> This updates the -00 version of the draft.
>> >> > > >>
>> >> > > >> Any comments/suggestions would be much appreciated.
>> >> > > >>
>> >> > > >> -Puneet and Bora
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >
>> >> > >
>> >> 
>> >> --
>> >> Eric Gray (mailto:[email-masked])
>> >> http://www.mindspring.com/~ewgray
>> >> 
>> >> 
>> >> 
>> >
>> 
>

---

From: Eric Gray <[email-masked]>
Date: Thu, 11 Oct 2001 17:17:42 -0400

Shahram,

    I agree with Puneet on the issue of 'TTL negotiation'.  This is not
analogous to DiffServ code point translation or some other activities.
In addition, the value that the service provider might use to decrement
TTL will be deterministic - a specific decrement value will most likely
be established as part of the SLA governing the relationship between
the service user and provider.

    There does not need to be a negotiation mechanism - primarily as a
result of the fact that there is no particular reason for either party to
care about the moment to moment changes in topology of the other
party, nor any particular reason for either party to want to expose this
information to the other party.

    But I also think that the two of you are talking past each other.  You
want it to be inflexible and thus deterministic while Puneet is pointing
out that it can be made deterministic precisely because it is flexible.  I
think everyone wants the behavior to be deterministic, but different
people want it to be deterministic in different ways for different uses.