Subject: TTL in ATM over MPLS

From: "Renwei Li" <[email-masked]>
Date: Wed, 26 Feb 2003 15:14:09 -0800

In the draft pwe3-atm-encap-01.txt, it says:

   The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a
value of 2.

IMHO, it is better to set to 255. The egress PE2 should discard the
packets if its TTL is other than 255. TTL 255 will prevent from the use
of VC label for transporting purpose.

Renwei

---

From: [email-masked]
Date: Thu, 27 Feb 2003 06:57:20 -0000

Renwei Li wrote 26 February 2003 23:14
> To: [email-masked]
> Subject: [PWE3] TTL in ATM over MPLS
> 
> 
NH=> Good point....but it has a downside:  If there is a defect that causes
misdelivery (ie swap/mismerge fault) then the traffic could be delivered to
wrong location.  Setting the TTL to 2 helps stop this possibility.

regards, Neil

---

From: John Fischer <[email-masked]>
Date: Thu, 27 Feb 2003 09:06:29 -0500

In addition, the tunneling context (could be an outer MPLS label)
may be popped at the penultimate node if PHP was requested by
the PE.  The inner label should only be exposed for 1 hop.  Setting
the TTL to 2 prevents the the packet from travelling any further than
it should need to go.
John

[email-masked] wrote:

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "David Allan" <[email-masked]>
Date: Thu, 27 Feb 2003 11:44:02 -0500

Correct me if I'm wrong, but for PHP scenarios, 255 is not what will be seen
at the egress PE. 

2 is the smallest value (hence smallest blast footprint ;-) that would not
decrement to zero prior to handling at the egress. No modifications to look
for special values are required.

Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 1:57 AM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] TTL in ATM over MPLS

> packets if its TTL is other than 255. TTL 255 will prevent from the 
> use of VC label for transporting purpose.

regards, Neil

---

From: "Renwei Li" <[email-masked]>
Date: Thu, 27 Feb 2003 10:15:33 -0800

For the PHP scenario, the tunnel label will be popped off, and the
egress PE should see 255 for VC label.
 
The main advantage for VC label TTL 255 will prevent some
mis-configurations.
 
Renwei

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 8:44 AM
To: [email-masked]'; Renwei Li; [email-masked]
Subject: RE: [PWE3] TTL in ATM over MPLS

	Correct me if I'm wrong, but for PHP scenarios, 255 is not what
will be seen at the egress PE. 

	2 is the smallest value (hence smallest blast footprint ;-) that
would not decrement to zero prior to handling at the egress. No
modifications to look for special values are required.

	Dave 

	-----Original Message----- 
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Thursday, February 27, 2003 1:57 AM 
	To: [email-masked]; [email-masked] 
	Subject: RE: [PWE3] TTL in ATM over MPLS 

	> use of VC label for transporting purpose. 
	NH=> Good point....but it has a downside:  If there is a defect
that causes misdelivery (ie swap/mismerge fault) then the traffic could
be delivered to wrong location.  Setting the TTL to 2 helps stop this
possibility.

	regards, Neil

---

From: "David Allan" <[email-masked]>
Date: Thu, 27 Feb 2003 13:38:04 -0500

Hi Renwei:
 
Depending on your implementation you'd see 255, 254 or depending on the
upstream implementation (as Shahram noted), you'll see the PSN TTL.
 
I would presume the value two in the specification provides coverage for
pipe mode, and how and when in the LSR forwarding sequence TTL handling is
implemented. TTL will explicit exhaust if forwarded beyond the PE, but will
not be deemed to have exhausted at precisely the moment it made it to the
PE. All bets are off for uniform as you lost that limiting property, but in
a well behaved system the payload would still be value. Cannot make that
claim for explicitly expecting 255.
 
Dave

-----Original Message-----
From: Renwei Li [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 1:16 PM
To: Allan, David [CAR:NS00:EXCH]; [email-masked]; [email-masked]
Subject: RE: [PWE3] TTL in ATM over MPLS

For the PHP scenario, the tunnel label will be popped off, and the egress PE
should see 255 for VC label.

Renwei

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 8:44 AM
To: [email-masked]'; Renwei Li; [email-masked]
Subject: RE: [PWE3] TTL in ATM over MPLS

Dave 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, February 27, 2003 1:57 AM 
To: [email-masked]; [email-masked] 
Subject: RE: [PWE3] TTL in ATM over MPLS 

regards, Neil 
_______________________________________________ 
pwe3 mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "Renwei Li" <[email-masked]>
Date: Thu, 27 Feb 2003 10:39:32 -0800

You are assuming the network is well-configured. But I am considering
what will happen if the network is not well-configured.

The bottom line is: when an LSR receives a packet with TTL 255, it is
sure that the packet was sent one hop away from. But if it receives a
packet with TTL 2, it is not sure how far the packet was sent away from.
Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from that. 

In view of the above, I believe you can easily give a mis-configured
network so that the egress PE receives a packet with TTL 2, but the
packet is not really a valid one sent from the ingress PE.

Renwei

---

From: "David Allan" <[email-masked]>
Date: Thu, 27 Feb 2003 16:36:41 -0500

A more realistic scenario is that the PW payload is leaked into the network
core, in which case if TTL=2, the misdirected traffic will "self destruct"
fairly quickly....

If you really want checking that stuff is not being misdirected at the PE,
TTL is hardly authoritative as all PWs will have the same value. I'd point
you to the FEC-CV proposed for 1711 as authoritative tests of connectivity
of a label.

Dave

BTW apologies if not plain text, still wrestling with new email s/w

-----Original Message-----
From: John Fischer [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 3:15 PM
To: Renwei Li
Cc: [email-masked]; [email-masked]; Allan, David [CAR:NS00:EXCH]
Subject: Re: [PWE3] TTL in ATM over MPLS

Yes you're correct, but I think that it would be quite difficult to get this
packet with a correct label and TTL=2 delivered to the PE in the first place
if that label was exposed for several hops.  The inner MPLS label is only
known by the PE in L2 VPN, L3 VPN and VPLS.

I agree that setting TTL to 255 and checking for 254/255 at the PE is more
secure.  As David Allan indicates though, this depends on the pipe or
uniform behaviour of the penultimate LSR and requires extra checks at the
PE.  By using TTL 2, basic TTL handling can be used at the PE. John

Renwei Li wrote:

> packet with TTL 2, it is not sure how far the packet was sent away 
> from. Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from 
> that.
>
> In addition, the tunneling context (could be an outer MPLS label) may
> be popped at the penultimate node if PHP was requested by the PE.  The 
> inner label should only be exposed for 1 hop.  Setting the TTL to 2 
> prevents the the packet from travelling any further than it should 
> need to go. John
>
> > >    The ingress LSR, PE1, SHOULD set the TTL field of the VC label
> > > to
> a
> > > value of 2.
> > >
> > > IMHO, it is better to set to 255. The egress PE2 should discard
> > > the packets if its TTL is other than 255. TTL 255 will prevent 
> > > from the use of VC label for transporting purpose.
> > regards, Neil _______________________________________________
> > pwe3 mailing list
> > [email-masked]

---

From: [email-masked]
Date: Fri, 28 Feb 2003 09:09:33 -0000

Just a small point here.....
 
Dave mentions the FEC-CV below which is being proposed/considered to augment
the simpler 'plain CV'......the plain CV is already an agreed format in
Y.1711.  The plain CV pkt contain the source identification of an LSP and I
would suggest this is used when p2p LSPs are considered.  ATM/MPLS
relationships are something we see as of increasing importance to get
right.......and I am not just referring to the client(ATM)/server(MPLS) case
but also the service-interworking case........where the plain CV is all one
needs IMO.
 
I agree with Dave wrt to the setting of the TTL, but my preference would be
to set this at 1 and don't do PHP.
 
regards, Neil

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: 27 February 2003 21:37
To: 'John Fischer'; Renwei Li
Cc: Harrison,N,Neil,IKL2 R; [email-masked]
Subject: RE: [PWE3] TTL in ATM over MPLS

Dave 

-----Original Message----- 
From: John Fischer [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, February 27, 2003 3:15 PM 
To: Renwei Li 
Cc: [email-masked]; [email-masked]; Allan, David [CAR:NS00:EXCH] 
Subject: Re: [PWE3] TTL in ATM over MPLS 

Renwei Li wrote: 

> From: John Fischer [ mailto:[email-masked]
<mailto:[email-masked]> ]