Subject: New revision of the MPLS ttl draft

From: Puneet Agarwal <[email-masked]>
Date: Mon, 8 Oct 2001 14:17:47 -0700

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

---

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Oct 2001 13:34:07 -0700

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
> 
>

---

From: Puneet Agarwal <[email-masked]>
Date: Tue, 9 Oct 2001 20:09:04 -0700

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  

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

---

From: Shahram Davari <[email-masked]>
Date: Wed, 10 Oct 2001 13:30:11 -0700

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

> 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
> >
> > > Sent: Tuesday, October 09, 2001 11:09 PM
> > > To: Shahram Davari; [email-masked]
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
>

---

From: Puneet Agarwal <[email-masked]>
Date: Wed, 10 Oct 2001 16:41:00 -0700

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

>Sent: Wednesday, October 10, 2001 1:30 PM
>To: 'Eric Gray'
>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:
>
>                       
>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.
>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
>

---

From: [email-masked]
Date: Thu, 11 Oct 2001 09:20:28 +0100

Shaham,

As I am sure you know having spoken with me on this several times, the only
architectural model that makes any sense when dealing with layer networks
(any technology) is that 'a client layer link connection (ie a single hop
between nodes at layer N say) is provided by a server layer trail connection
at layer N+1'.  The key observation is that the number of hops (=link
connections) that constitute the server layer trail can be arbitrary.  And
note carefully that *each* of the link connections of the trail at layer N+1
can in turn be composed of further lower (server) layer trail connections at
layer N+2.  This relationship recurses to the duct network.

It makes no sense to try and predict/guess the number of server layer link
connections at all levels below the layer of interest because:
-	they are not necessarily known (ie the recursion issue);
-	they may be owned by some other party providing a transit service
(which you note below);
-	the number of *link connections* that compose a sever layer trail
(at *any* level below that of interest) could very easily change due to
protection-switching....and one would not want (or necessarily be able) to
review some 'guessed' TTL decrement at a higher layer level.

So the only architectural view that makes any sense is where the TTL is
treated independently at each layer network.

Option B below makes no sense.....it requires (in the example you gave) a
different party to know the number of link connections in someone else's
network (and also know when this changes, say due to prot-sw).

So only option A is therefore viable (and I note you prefer this
anyway)....however, it still requires the predicting of TTL decrement,
though now it is under the control of the same party.  To cater for the case
of prot-sw say where the number of link connections may change (say between
E and H), I guess one could set a fixed decrement that was not necessarily
related to the exact number of link connections.  However, I'm not at all
sure this gives any *real* benefits, since the efficacy of TTL is only
realised when it is indeed decremented on a link connection basis.

regards, Neil

> Sent: 10 October 2001 21:30
> To: 'Eric Gray'
> 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.
> My argument is that the Short pipe model should fulfill 
> method B, and Pipe model should fulfill method A.
> 
> 
> Yours,
> -Shahram
><snipped to end NH>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 11 Oct 2001 06:16:13 -0700

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

> Sent: Wednesday, October 10, 2001 7:41 PM
> To: Shahram Davari; 'Eric Gray'
> Cc: Puneet Agarwal; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Thu, 11 Oct 2001 06:25:38 -0700

Hi Neil,

Thanks for your comments. The Pipe model was introduced exactly for the reasons that you described. The short pipe model was introduced for those who want their server layer have knowledge of their client layer and manipulate their client layer.

I fact the pipe model was added to the mpls-diff-ext draft in one of the its latest versions, and the reason was that people were asking for it. 

Both models were introduced to let people choose whichever model they like. 

Yours,
-Shahram

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 4:20 AM
> To: Shahram Davari; [email-masked]
> Cc: [email-masked]; [email-masked]