Subject: Re: TTL value of VC Label?

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 May 2003 14:56:04 +0100

We changed it to the value 2

This is large enough that it will always get delivered
even in a PHP system, small enough that it goes the
minimum distance if accidentally released as a top label,
and requires no special checking.

Stewart

Yaron Nachman wrote:
> Hi,
> 
> I have just noticed that in the yesterday-updated
> draft-martini-l2circuit-encap-mpls-05.txt, the TTL value to be placed by an
> Ingress LER on the VC Label is 2.
> I have noticed in the past that it was changed to 255.
> 
> So, is it 2 or 255? or even some other value??
> 
> Thanks,
> 
> Yaron Nachman
> 
> SEABRIDGE Ltd.
> Tel:       972-9-7751359
> Fax:      972-9-7751212
> E-mail:  [email-masked]
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>

---

From: Alik Shimelmits <[email-masked]>
Date: Thu, 1 May 2003 19:47:06 +0200

I agree with Eric
	Alik

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Thursday, May 01, 2003 4:56 PM
To: [email-masked]
Cc: Yaron Nachman; [email-masked]'; Eli Angel; Ilya Vershkov
Subject: Re: [PWE3] TTL value of VC Label? 

Stewart> We changed it to the value 2

I don't think this is a good idea.

Suppose one of the two attachment  circuits bound together by a pw is itself
a pw.  Now you'd like ordinary MPLS  switching to be able to move the packet
from  one  pw to  the  other,  but  the TTL  of  2  will prevent  this  from
happening. 

The "Distributed VPLS"  model also gives rise to a number  of cases in which
one wants to splice together two pws. 

I don't  think there  should be any  requirement on  the setting of  the TTL
value. 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Wei Luo <[email-masked]>
Date: Thu, 01 May 2003 11:08:02 -0700

In the PW splicing scenario, it's not really the same as normal MPLS switching. 
Typically, one PW is terminated at the splicing PE and another (different PW) is
initiated.  This means packets arrived from one PW will remove its current PW
encapsulation, e.g. tunnel and vc labels, and then add a new PW encapsulation. 
In this way, it allows the data path to have a unified packet processing
behavior regardless what PW encapsulation is used in each leg.  For example,
MPLS PW - MPLS PW, MPLS PW - L2TP PW, L2TP PW - MPLS PW, L2TP PW - L2TP PW can
all have the same data plane implementation, instead of one flavor for a
different combination.  I am speaking of what's more suitable from
implementation point of view.

In the PW splicing case, the TTL of 2 would work.  Of course, simply specifying
it anything larger than 2 would work too.

---Wei

---

From: Skip Booth <[email-masked]>
Date: Thu, 1 May 2003 15:23:04 -0400 (Eastern Daylight Time)

On Thu, 1 May 2003, Eric Rosen wrote:

>
> Eric> If you're splicing  together two MPLS pseudowires, you  should be able
> Eric> to use  existing MPLS forwarding  hardware, and just do  ordinary MPLS
> Eric> label replacement with ordinary MPLS TTL processing.
>
> Skip> Not  quite true  as you  would  want to  go through  the control  word
> Skip> processing including any sequence number options.
>
> I don't  think so, the  control word processing  should only be done  at the
> ultimate endpoint, there's no point to doing it multiple times.

That may be true for end to end AToM, like to like cases.  However, that
wouldn't be true for AToM to L2TP tunnel splicing.  Nor would it be true for
AToM any2any processing if the tunnel splicing box was the a2a enforcement
point.

Also, even for the like2like case, it may be important to do the sequencing
checks at the tunnel-splicer just to provide the diagnostic information needed
to determine where the sequencing errors are occurring.  This could translate
into a billing issue if there was packet loss as a result of sequence errors.
It's certainly a service issue which needs to be diagnosed in the appropriate
part of the network.

-Skip

---

From: Olen Stokes <[email-masked]>
Date: Thu, 1 May 2003 17:16:18 -0700

As Vach says, being able to set the TTL to something other than 2 is very
important to being able to provide a "traceroute" capability (in addition to
protection against loops).

Cheers,
Olen

> From: Vach Kompella [mailto:[email-masked]]
> Sent: Thursday, May 01, 2003 2:30 PM
> To: Wei Luo; Alik Shimelmits
> Cc: [email-masked]; [email-masked]; Yaron Nachman; 
> [email-masked];
> Eli Angel; Ilya Vershkov
> Subject: RE: [PWE3] TTL value of VC Label?
> 
> 
> I too would like to see the value not specified as 2.  
> Splicing PWs as a L2
> service and still having a TTL is a secondary security 
> against loops for a
> service that extends beyond the scope of the tunnel.  It also 
> provides nice
> "traceroute" capabilities, with L2 service aware nodes 
> handling TTL expiration.
> 
> -Vach
> 
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Wei
> > Luo
> > Sent: Thursday, May 01, 2003 11:08 AM
> > To: Alik Shimelmits
> > Cc: [email-masked]; [email-masked]; Yaron Nachman;
> > [email-masked]'; Eli Angel; Ilya Vershkov

---

From: "Brian Hassink" <[email-masked]>
Date: Fri, 2 May 2003 06:44:47 -0400

Shouldn't the usage of TTL with respect to VC labels be specified in one of the architectural or functional drafts so that the scenarios and their issues can be fully explored, and best common practices can be specified (some of which has been done in this thread)?
 
The MIB should take its queue from this specification, not do it itself. If there's ambiguity in the MIB, then something hasn't been properly specified in the architectural or functional drafts.
 
Cheers,
Brian

	-----Original Message----- 
	From: Stewart Bryant [mailto:[email-masked]] 
	Sent: Fri 5/2/2003 4:00 AM 
	To: Olen Stokes 
	Cc: [email-masked]'; Wei Luo; Alik Shimelmits; [email-masked]; Yaron Nachman; [email-masked]; Eli Angel; Ilya Vershkov 
	Subject: Re: [PWE3] TTL value of VC Label?

	I could delete the TTL = 2 completely, but there was 
	some discussion on the list that caused me to add it 
	in the first place, so how about either something of 
	the form: 

	"Ideally the TTL should be a small value to prevent the 
	looping of PW packets in misconfigured or malfunctioning 
	MPLS networks. In choosing a suitable TTL value, the 
	user should give consideration to any PHP systems and 
	concatonated PWs." 

	If it needs to be any more complex than this, I will 
	just delete the sentence. 

	Stewart

---

From: Olen Stokes <[email-masked]>
Date: Fri, 2 May 2003 05:44:24 -0700

I would be happy with a statement that says when used in a point-to-point PW
environment, the TTL should be set to 2.  This could be combined with a
statement that says when used in other environments, such as concatenated
PWs, the setting shall be as specified in the standards defining those
environments.

For example, in draft "draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt," we
defined a method for setting the TTL and also how the TTL is to be handled
as it passes between the concatenated PWs.

Cheers,
Olen

> From: Brian Hassink [mailto:[email-masked]]
> Sent: Friday, May 02, 2003 6:45 AM
> To: [email-masked]; Olen Stokes
> Cc: [email-masked]; Wei Luo; Alik Shimelmits; [email-masked];
> Yaron Nachman; [email-masked]; Eli Angel; Ilya Vershkov
> Shouldn't the usage of TTL with respect to VC labels be 
> specified in one of the architectural or functional drafts so 
> that the scenarios and their issues can be fully explored, 
> and best common practices can be specified (some of which has 
> been done in this thread)?
>  
> The MIB should take its queue from this specification, not do 
> it itself. If there's ambiguity in the MIB, then something 
> hasn't been properly specified in the architectural or 
> functional drafts.
>  
> Cheers,
> Brian
>  
> 
> 	Cc: [email-masked]'; Wei Luo; Alik Shimelmits; 
> [email-masked]; Yaron Nachman; [email-masked]; Eli Angel; 
> Ilya Vershkov

---

From: Eric Rosen <[email-masked]>
Date: Fri, 02 May 2003 09:49:06 -0400

Chris> Two providers sharing an  inter-AS link (independent of whether these
Chris> are  PW or  IP packets)  at an  exchange point  may establish  a paid
Chris> peering  relationship based on  the amount  of traffic  exchanged. So
Chris> counting PW packets that cross AS boundaries may be a requirement. 

Yes, but  that's not the issue.  The  issue is the following:  if provider A
sends 100 packets to provider B, but 50 of them are out of sequence, do they
count against  the amount of traffic  exchanged?  Do you  think one provider
would tell  another "I'm  not paying for  that packet  because it is  out of
sequence?"  Maybe the answer depends on whether the cost of doing that check
eats up all the savings ;-)

---

From: George Swallow <[email-masked]>
Date: Mon, 05 May 2003 15:46:28 -0400

> as it passes between the concatenated PWs.

If you're doing a 802.1d bridging function between PWs, they are not
concatenated PWs.  What Eric Rosen was discussing is simply splicing
based on the VC label.  Not by looking at MAC addresses.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: Eric Rosen <[email-masked]>
Date: Mon, 05 May 2003 16:21:55 -0400

David> Setting the TTL is application dependant.  The originating PE will know
David> if the PSN tunnel reaches the destination node for the PW.  

I don't think it will always know this.

David> In other cases,  for example, DTLS, a  TTL of 4 may be  needed due to
David> the two additional hops taken between the L2PE and PE at each end.

You could have an L2PE/PE hop at  one end but not at the other.  In general,
you wouldn't know whether the other end has such a hop or not.

---

From: Danny McPherson <[email-masked]>
Date: Fri, 09 May 2003 15:23:13 -0600

On 5/7/03 3:49 PM, "Luca Martini" <[email-masked]> wrote:

> How about this ?
> 
> "The setting of the TTL value in the PW
> label is application dependent, however in a strict point to point application
> the TTL should be appropriately set to 2"

I like this.  Does anyone have objections to updating the current document
with something along these lines?

-danny