Subject: Re: Different TTLs

From: John Smith <[email-masked]>
Date: Wed, 1 Jun 2011 14:39:55 +0100 (BST)

Would be great if somebody can answer this!

----- Original Message ----
From: John Smith <[email-masked]>
To: [email-masked]
Sent: Tue, 31 May, 2011 4:27:45
Subject: Different TTLs

Hi,

I would like to understand the relation between the TTL carried in the BGP label 

and the IP payload in the L3 VPN scenarios. As per my understanding it will 
always be the same as IP TTL. Is there any scenario when it will be different 
from the IP TTL. I understand that there are different models for carrying the 
transport TTL. In one model the IP TTL is copied to the transport label, which 
is reduced by each P hop and is finally copied back to the IP TTL field at the 
egress PE router. In this case the IP TTL gets decremented by as many hops as 
exist in the service provider network. In another, the TTL of the transport 
label is kept as 255 and is decremented at each hop. The IP TTL is preserved and 

the customer is oblivious to the service provider topology.

Is my understanding of the two models correct?

Now, my question is what do we do about the TTL carried in the second label (the 

BGP label)? Should it be kept as 255 or should we copy the IP TTL. Whats the use 

of setting any TTL there as this label is never exposed (unless someone is using 

implicit null at the egress that is).

Thanks, John

---

From: John Smith <[email-masked]>
Date: Wed, 1 Jun 2011 23:47:03 +0100 (BST)

Don,

Thanks for confirming this.

My doubt is specifically wrt the BGP label thats carried in the data packet. 
What TTL should that be set to? And is it ever modified? Note that the BGP label 
is never really exposed, unless there is PHP or something. Is the TTL of the 
inner label (the BGP label) set to the TTL as the IP payload? And if Yes, then 
will it *ever* be different than the IP TTL when it reaches the other remote PE 
router?

Thanks, John

----- Original Message ----
From: Don Heidrich (dheidric) <[email-masked]>
To: John Smith <[email-masked]>
Sent: Wed, 1 June, 2011 20:43:25
Subject: RE: Different TTLs

John,

Your assumptions are correct, one way the customer can see and trace the SP 
network routers, the other the SP network appears as one hop.

Re label TTL - as labels are pushed and popped at various hops the TTL is copied 
to the outer label. At the last MPLS router (or penultimate) we have the option 
to copy TTL back into the IP header or not.

-Don

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Smith
> Sent: Wednesday, June 01, 2011 9:40 AM
> To: [email-masked]
> Subject: Re: Different TTLs
>

---

From: <[email-masked]>
Date: Fri, 3 Jun 2011 11:42:41 +0200

Hi,

Each label level is representing a specific level of tunneling.

If you consider Uniform model, and service+transport MPLS, MPLS TTL is set IP TTL value when PE is doing encapsulation (double push). When penultimate hop is popping transport label, TTL of transport label is copied back to service label. When service label is popped, TTL is copied back to IP layer. 

If you consider "Short pipe", MPLS TTL is set to 255 when PE is doing encapsulation (double push). When penultimate hop is popping transport label, TTL of transport label is NOT copied back to service label. When service label is popped, TTL is copied NOT back to IP layer.
"Pipe model" is same as short pipe but no PHP.

The service label TTL treatment is more "meaningful" imo when you have a real tunnel at service level : the more easy example is interAS VPN option B when you are swapping VPN labels at ASBR side or Carrier Support Carrier case too, when transport label of customer is swapped to Carrier VPN label.

Purely "Theorically" speaking each tunnel level (service tunnels or nested transport tunnels) is independent in term of TTL behavior (and depends of configuration of Headend/Tailend Tunnel nodes, especially when you have nested tunnels (based LDP over RSVP ...).

Hope it helps,

Best Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de John Smith
Envoyé : jeudi 2 juin 2011 00:47
À : Don Heidrich (dheidric)
Cc : [email-masked]
Objet : Re: Different TTLs

Don,

My doubt is specifically wrt the BGP label thats carried in the data packet. 
What TTL should that be set to? And is it ever modified? Note that the BGP label is never really exposed, unless there is PHP or something. Is the TTL of the inner label (the BGP label) set to the TTL as the IP payload? And if Yes, then will it *ever* be different than the IP TTL when it reaches the other remote PE router?

Thanks, John

----- Original Message ----
From: Don Heidrich (dheidric) <[email-masked]>
To: John Smith <[email-masked]>
Sent: Wed, 1 June, 2011 20:43:25
Subject: RE: Different TTLs

John,

Your assumptions are correct, one way the customer can see and trace the SP network routers, the other the SP network appears as one hop.

Re label TTL - as labels are pushed and popped at various hops the TTL is copied to the outer label. At the last MPLS router (or penultimate) we have the option to copy TTL back into the IP header or not.

-Don

> and the IP payload in the L3 VPN scenarios. As per my understanding it 
> will always be the same as IP TTL. Is there any scenario when it will 
> be different from the IP TTL. I understand that there are different 
> models for carrying the transport TTL. In one model the IP TTL is 
> copied to the transport label, which is reduced by each P hop and is 
> finally copied back to the IP TTL field at the egress PE router. In 
> this case the IP TTL gets decremented by as many hops as exist in the 
> service provider network. In another, the TTL of the transport label 
> is kept as 255 and is decremented at each hop. The IP TTL is preserved 
> and
> 

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jun 2011 17:49:39 -0700

> Purely "Theorically" speaking each tunnel level (service tunnels or nested transport tunnels) is independent in term of TTL behavior (and depends of configuration of Headend/Tailend Tunnel nodes, e…

That makes sense regarding the tunnel, but the ingress/egress ought to 
be decrementing the TTL since they behave as RFC1812 routers if they're 
not strictly the source/sink of the packets entering the tunnel.

Joe

> From: Don Heidrich (dheidric)<[email-masked]>
> To: John Smith<[email-masked]>
>> From: John Smith<[email-masked]>
>> To: [email-masked]