Subject: [mpls-tp] short working group last call on draft-ietf-mpls-tp-framework-11

From: Loa Andersson <[email-masked]>
Date: Sat, 03 Apr 2010 11:31:19 +0200

All,

this is to start a short working group last call on "A Framework
for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the orevious working group last call and reviews have
been correctly addressed.

Please sen comments to the mpls-tp mailing list on April 17th, the
latest.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 8 Apr 2010 11:59:48 -0700

Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we know traditional transport layers only have one CoS. However E-LSP has multiple CoS, which can reorder packets (I know that the reorder packets belong to different CoS). Additionally the definition of E-LSP OAM and performance and protection and availability, etc will be questionable (because of carrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least should be discouraged.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

All,

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Apr 2010 12:20:36 -0700

Sharam,

We have been through this at least twice before.  The best way to think E-LSPs is that the former EXP bits in the header are part of an extended label.  So you effectively have eight parallel LSPs and there is no packet re-ordering within each.

Dave said he would mention something about OAM per parallel LSP in the framework in response to a last call comment I made.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Thursday, April 08, 2010 12:00 PM
> To: Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc team;
> [email-masked]; CCAMP
> Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf-
> mpls-tp-framework-11
> 
> Hi Loa,
> 
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As
> we know traditional transport layers only have one CoS. However E-LSP has
> multiple CoS, which can reorder packets (I know that the reorder packets
> belong to different CoS). Additionally the definition of E-LSP OAM and
> performance and protection and availability, etc will be questionable
> (because of carrying multiple CoS).
> 
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 8 Apr 2010 12:30:03 -0700

Hi John,

Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of them fail do protection switching for all of them? What will be the definition of availability for such E-LSP? 

Thanks
SD

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 12:21 PM
To: Shahram Davari; Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Sharam,

Thanks,

John

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Apr 2010 12:30:59 -0700

Dear Shahram,
I share your concern regarding applicability of E-LSP in packet transport
network. Though the document is about the Transport Profile, references to
MPLS-TP as packet transport network technology been changed recently. Now
MPLS-TP is referred as "packet network". It is my understanding that
applicability of MPLS-TP functionality, features and capabilities to the
packet transport network will be decided later, separately.
Regarding classes of service in the transport. Neil Harrison pointed several
times that a connection, transport path cannot have multiple classes,
otherwise it leads to significant increased complexity of OAM, which has to
be (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Apr 2010 12:33:25 -0700

Hi Shahram,
as John mentioned, OAM per CoS for E-LSP was discussed on another thread. I
believe that we agreed that OAM SHOULD be per CoS. Right?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:30 PM, Shahram Davari <[email-masked]> wrote:

> Hi John,
>
> Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of
> them fail do protection switching for all of them? What will be the
> definition of availability for such E-LSP?
>
> Thanks
> SD
>
> To: Shahram Davari; Loa Andersson; [email-masked]; [email-masked];
> MPLS-TP ad hoc team; [email-masked]; CCAMP
> We have been through this at least twice before.  The best way to think
> E-LSPs is that the former EXP bits in the header are part of an extended
> label.  So you effectively have eight parallel LSPs and there is no packet
> re-ordering within each.
>
> Dave said he would mention something about OAM per parallel LSP in the
> framework in response to a last call comment I made.
>
> Thanks,
>
> John
>

---

From: David Allan I <[email-masked]>
Date: Thu, 8 Apr 2010 15:45:19 -0400

I'm not quite following this argument....

If I have a number of co-routed paths with different PHBs, I can instantiate a number of L-LSPs, which is a significant amount of state at every hop, or I can instantiate one E-LSP, which is an N:1 compression in the amount of state in transit nodes.

The only wrinkle is all PHBs of an E-LSP fate share. But then if I was protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majority of failure cases (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched (although there would be 'n' signal fail indications internally to contend with). Overall, it sounds to me like an E-LSP may be a bit faster there....

The actual OAM load to instrument them equally is the same. If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs so what????  I appreciate that the ability to generate per PHB flows may be undesirable for some, but that does not make it a bad idea.

IMO there is no penalty for supporting E-LSPs and there are measurable benefits. The analysis is flawed.

my 2 cents
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc: [email-masked]; MPLS-TP ad hoc team; CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately.
Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

Regards,
Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

All,

/Loa
--

Loa Andersson                         email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13
_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Apr 2010 12:51:31 -0700

Dave,

My only comment is with your last sentence:  "The analysis is flawed."  To be clearer, it should be:  "The analysis that concludes that E-LSPs are a bad idea is flawed."

Your analysis seems completely correct.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Allan I
> Sent: Thursday, April 08, 2010 12:45 PM
> To: Greg Mirsky; Shahram Davari
> Cc: [email-masked]; CCAMP; MPLS-TP ad hoc team; [email-masked]; mpls-
> [email-masked]
> If I have a number of co-routed paths with different PHBs, I can
> instantiate a number of L-LSPs, which is a significant amount of state at
> every hop, or I can instantiate one E-LSP, which is an N:1 compression in
> the amount of state in transit nodes.
> 
> The only wrinkle is all PHBs of an E-LSP fate share. But then if I was
> protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or
> another E-LSP, and if they were co-routed, the majority of failure cases
> (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was
> switched (although there would be 'n' signal fail indications internally
> to contend with). Overall, it sounds to me like an E-LSP may be a bit
> faster there....
> 
> The actual OAM load to instrument them equally is the same. If an E-LSP
> takes 'n' times the flows to be instumented like 'n' L-LSPs so what????  I
> appreciate that the ability to generate per PHB flows may be undesirable
> for some, but that does not make it a bad idea.
> 
> Regarding classes of service in the transport. Neil Harrison pointed
> several times that a connection, transport path cannot have multiple
> classes, otherwise it leads to significant increased complexity of OAM,
> which has to be (SHOULD) per Class of Service per E-LSP.
> 
> Regards,
> Greg
> 
> 
> 	The draft mentions that both L-LSP and E-LSP are supported in MPLS-
> TP. As we know traditional transport layers only have one CoS. However E-
> LSP has multiple CoS, which can reorder packets (I know that the reorder
> packets belong to different CoS). Additionally the definition of E-LSP OAM
> and performance and protection and availability, etc will be questionable

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Apr 2010 12:57:12 -0700

Dear David,
my understanding of pro-active CV/CC when applied to E-LSP is that all
supported CoS will be run at all time regardless whether a particular class
ever used. Though that might be taken care of by a intelligent OAM
implementation. The protection of N L-LSPs might be done through PST to
reduce the bang level.
In my view both methods to do DiffServ in MPLS have proven itself. Both have
merits and drawbacks. Both are part of MPLS-TP. Will they be both part of
packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I
<[email-masked]>wrote:

> switched (although there would be 'n' signal fail indications internally to
> contend with). Overall, it sounds to me like an E-LSP may be a bit faster
> there....
>
> appreciate that the ability to generate per PHB flows may be undesirable for
> some, but that does not make it a bad idea.
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Greg Mirsky
> *Sent:* Thursday, April 08, 2010 3:31 PM
> *To:* Shahram Davari
> *Cc:* [email-masked]; MPLS-TP ad hoc team; CCAMP; [email-masked];
> [email-masked]
> *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on
> draft-ietf-mpls-tp-framework-11
>
> Dear Shahram,
> On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <[email-masked]>wrote:
>
>> Hi Loa,
>>

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Apr 2010 12:56:14 -0700

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 12:30 PM
> To: John E Drake; Loa Andersson; [email-masked]; [email-masked]; MPLS-TP
> ad hoc team; [email-masked]; CCAMP
> Thanks. Does that mean one needs to run 8 BFDs on that E-LSP
[JD] 

I think that might be gilding the lily.  Since, except for the buffer, queuing, and scheduling, the eight are tightly coupled, one CV/CC is probably fine.  Performance monitoring by PHB is probably a good thing.

> and if any of
> We have been through this at least twice before.  The best way to think E-
> LSPs is that the former EXP bits in the header are part of an extended

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Apr 2010 13:09:40 -0700

Dear John,
I think that especially because of all things you've mentioned "... except
for the buffer, queuing, and scheduling, ..." even CV/CC will have to be ran
per CoS. Otherwise, CV/CC be ignoring PHB. It might be unlikely situation
unless operator oversubscribes resources. I'd "be prepared".

Regards,
Greg

On Thu, Apr 8, 2010 at 12:56 PM, John E Drake <[email-masked]> wrote:

> I think that might be gilding the lily.  Since, except for the buffer,
> queuing, and scheduling, the eight are tightly coupled, one CV/CC is
> probably fine.  Performance monitoring by PHB is probably a good thing.
>
> > and if any of
> E-
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > > Loa Andersson
> > > To: [email-masked]; [email-masked]; MPLS-TP ad hoc team;
> [email-masked];
> > > CCAMP

---

From: David Allan I <[email-masked]>
Date: Thu, 8 Apr 2010 16:11:19 -0400

Hi Greg:

yes there is a ying and yang to this.

But "a" PST that could stunt double for many L-LSPs would have to be an E-LSP itself. else an L-LSP matching the highest PHB of the set of L-LSPs carried. The alternative being 'n' PSTs. So you end up with either undifferentiated treatment of the original set of L-LSPs or 2x'N' OAM flows no matter how you cut it. ....

I agree that for E-LSPs additional intelligence/configuration would be needed to only instrument the PHBs that were geninue bearers...

Meanwhile, I believe this dialog started because both methods are already in packet transport, at least as being specified by this effort. That was being questioned.

cheers
D

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 3:57 PM
To: David Allan I
Cc: Shahram Davari; [email-masked]; MPLS-TP ad hoc team; CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Dear David,
my understanding of pro-active CV/CC when applied to E-LSP is that all supported CoS will be run at all time regardless whether a particular class ever used. Though that might be taken care of by a intelligent OAM implementation. The protection of N L-LSPs might be done through PST to reduce the bang level.
In my view both methods to do DiffServ in MPLS have proven itself. Both have merits and drawbacks. Both are part of MPLS-TP. Will they be both part of packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
I'm not quite following this argument....

my 2 cents
D

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team; CCAMP; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,

Regards,
Greg

Regards,
Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

All,

/Loa
--

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Apr 2010 18:38:19 -0700

Dear Shahram,
I agree that defining criteria for E-LSP availability as function of per-CoS
availability is not a trivial task. I would say that an operator should be
given flexibility to weight differently availability of individual CoS of a
particular E-LSP (or that could be per specified group, domain). That is
implementation detail, but in a PM document we might say that it is a
function of per-CoS measured availabilities.

Regards,
Greg

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Apr 2010 00:18:28 -0400

In message <[email-masked]>
John E Drake writes:
> Dave said he would mention something about OAM per parallel LSP in
> the framework in response to a last call comment I made. 
>  
> Thanks,
>  
> John

John,

Anyone using AF service would be very mad at you if you reordered
based on TC bits aka EXP.

Groups of TC values remain ordered.  For AF it is a group of 3.  For
the old IPprec (CS service) it is 8 discrete PHB and each remains
ordered but the higher priorities can get queued first.

But otherwise I agree.  QoS is important.

Curtis

> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Apr 2010 00:30:09 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Hi John,
>  
> Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if
> any of them fail do protection switching for all of them? What will be
> the definition of availability for such E-LSP?
>  
> Thanks
> SD

If there were multiple priorities on an LSP the OAM should be at a
high priority.  For example for CS service (the old IP prec) CS6 is
normally used for control traffic.  If OAM failed for CS6 the link is
down.  If OAM fails for CS0 the link may just be oversubscribed and
contested but CS0 is defined as the best effort (BE) service.

A provider may choose to do this.  For example, if VOIP ran at CS4 and
worked fine and web and email was runnig on CS0, phone would work and
web would be slow.  If a natural disaster took out 3/4 of the network
capacity, then having working phone and slow web and maybe unworkable
web streaming video might be better than prohibiting oversubscription
and having no service at all.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Apr 2010 00:44:41 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
>  
> Dear Shahram,
>  
> I share your concern regarding applicability of E-LSP in packet
> transport network. Though the document is about the Transport Profile,
> references to MPLS-TP as packet transport network technology been
> changed recently. Now MPLS-TP is referred as "packet network". It is
> my understanding that applicability of MPLS-TP functionality, features
> and capabilities to the packet transport network will be decided
> later, separately.  Regarding classes of service in the
> transport. Neil Harrison pointed several times that a connection,
> transport path cannot have multiple classes, otherwise it leads to
> significant increased complexity of OAM, which has to be (SHOULD) per
> Class of Service per E-LSP.
>  
> Regards,
> Greg

Greg,

Reality check!  MPLS-TP needs to:

  Provide an ability to deliver a service that has the characteristis
  of a transport network should anyone decide to use it that way.

  Also provide a solution that has certain important characteristis of
  a transport network but eliminates the characteristis of a transport
  network that make it not cost effective.  Among the things that need
  to go is a hard guarentee on bandwidth for every service, including
  the lowest priority services.

Otherwise we might as well just use circuits or allocate time slots to
fixed sized MPLS packets.

Curtis

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 09:24:25 +0200

Shahram,

> As we know traditional transport layers only have 
> one CoS.

This is no more the case after Ethernet transport layer has been developed.

> Additionally the definition of E-LSP OAM and 
> performance and protection and availability, etc will be 
> questionable (because of carrying multiple CoS).

I agree that performance monitoring for multi-CoS connections (e.g., E-LSP) is not trivial. We have exactly the same issue with Ethernet performance monitoring.

In principle I think that a solution can be defined but I am spending too much time on mpls-tp standardization so I had not time to monitor the status of this work within Q14/15.

I do not see any issue with fault monitoring of multi-CoS connections as faults are not per-CoS but per-connection.

Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shahram Davari
> Sent: giovedì 8 aprile 2010 21.00
> To: Loa Andersson; [email-masked]; [email-masked]; MPLS-TP 
> Subject: Re: [mpls] [PWE3] short working group last call on 
> The draft mentions that both L-LSP and E-LSP are supported in 
> MPLS-TP. As we know traditional transport layers only have 
> one CoS. However E-LSP has multiple CoS, which can reorder 
> packets (I know that the reorder packets belong to different 
> CoS). Additionally the definition of E-LSP OAM and 
> performance and protection and availability, etc will be 
> questionable (because of carrying multiple CoS).
> 
> this is to start a short working group last call on "A 
> Framework for MPLS in Transport Networks" 
> (draft-ietf-mpls-tp-framework-11).
> 
> Please note that this wg last call is limited to verify that 
> comments raised during the orevious working group last call 
> and reviews have been correctly addressed.
> 
> Please sen comments to the mpls-tp mailing list on April 
> 17th, the latest.
> 
> /Loa
> -- 
> 
> 
> Loa Andersson                         email: 
>                                               +46 767 72 92 
> 13 _______________________________________________
> pwe3 mailing list
> [email-masked]

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 09:28:11 +0200

I think that running OAM flows per-PHB, while very much appropriate for PM tools (as already documented in the OAM frameworkd draft), is actually an overdesign for FM tools.
 
Misconnections and failures are per-LSP and not per-PHB.
 
Italo

 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
	Sent: giovedì 8 aprile 2010 21.45
	To: Greg Mirsky; Shahram Davari
	Cc: [email-masked]; CCAMP; MPLS-TP ad hoc team; [email-masked]; [email-masked]
	Subject: Re: [CCAMP] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11

	 

	 
	my 2 cents
	D

	Dear Shahram,
	
	Regards,
	Greg

		Hi Loa,

		
		Regards,
		Shahram

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
		Sent: Saturday, April 03, 2010 2:31 AM
		To: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
		Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11
		
		All,

		
		
		/Loa
		--

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 09:36:47 +0200

> [JD] 
> 
> I think that might be gilding the lily.  Since, except for 
> the buffer, queuing, and scheduling, the eight are tightly 
> coupled, one CV/CC is probably fine.  Performance monitoring 
> by PHB is probably a good thing.

I cannot agree more.

Italo

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of John E Drake
> Sent: giovedì 8 aprile 2010 21.56
> To: Shahram Davari; Loa Andersson; [email-masked]; 
> [email-masked]; MPLS-TP ad hoc team; [email-masked]; CCAMP
> > To: John E Drake; Loa Andersson; [email-masked]; [email-masked]; 
> > Subject: RE: [mpls] [PWE3] short working group last call on 
> > draft-ietf-
> > mpls-tp-framework-11
> > 
> > Hi John,
> > 
> I think that might be gilding the lily.  Since, except for 
> the buffer, queuing, and scheduling, the eight are tightly 
> coupled, one CV/CC is probably fine.  Performance monitoring 
> by PHB is probably a good thing.
> 
> > and if any of
> > MPLS- TP ad hoc team; [email-masked]; CCAMP
> > Subject: RE: [mpls] [PWE3] short working group last call on 
> > draft-ietf-
> > mpls-tp-framework-11
> > 
> > Sharam,
> > 
> > We have been through this at least twice before.  The best way to 
> > think E- LSPs is that the former EXP bits in the header are 
> part of an 
> > extended label.  So you effectively have eight parallel 
> LSPs and there 
> > is no packet re-ordering within each.
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Shahram Davari
> > > To: Loa Andersson; [email-masked]; [email-masked]; 
> MPLS-TP ad hoc 
> > > The draft mentions that both L-LSP and E-LSP are 
> supported in MPLS-TP.
> > As
> > > we know traditional transport layers only have one CoS. However 
> > > E-LSP
> > has
> > > multiple CoS, which can reorder packets (I know that the reorder 
> > > packets belong to different CoS). Additionally the definition of 
> > > E-LSP OAM and performance and protection and 
> availability, etc will 
> > > be questionable (because of carrying multiple CoS).
> > >
> > > Of Loa Andersson
> > > Subject: [PWE3] short working group last call on 
> draft-ietf-mpls-tp-
> > > framework-11
> > >
> > > All,
> > >
> Framework for 
> > > MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).
> > >
> > > comments raised during the orevious working group last call and 
> > > reviews have been correctly addressed.
> > >
> 17th, the

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 9 Apr 2010 00:33:56 -0700

Dear Italo,
if we consider Link Bundle (RFC 4201) then it is possible that some CoS
flows are  being mapped to a different component links. In this case per CoS
FM is quite necessary.

Regards,
Greg

On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO
<[email-masked]>wrote:

>  I think that running OAM flows per-PHB, while very much appropriate for
> PM tools (as already documented in the OAM frameworkd draft), is actually an
> overdesign for FM tools.
>
> Of *David Allan I
> *Sent:* giovedì 8 aprile 2010 21.45
> *To:* Greg Mirsky; Shahram Davari
> *Cc:* [email-masked]; CCAMP; MPLS-TP ad hoc team; [email-masked];
> [email-masked]
> *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last callon

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Apr 2010 09:35:27 +0200

E-LSPs (and E-PWs) seem to be more appreciated by customers then L-LSPs
(L-PWs) I am told by an operator. If an E-LSP/E-PW breaks, then there is no
connectivity for any of the CoS levels. Partial failure of a multi-CoS
service (i.e. for one of the CoS levels) is considered to be bad.
 
Main service these days is Ethernet and Ethernet VLANs are by default
supporting multiple CoS levels.
 
Most of the OAM checks if the transport path is present. Only the packet
loss measurement and packet delay measurement OAM checks treatment of client
flows. So only those two OAM types may need per CoS measurements. This is
not different from Ethernet OAM.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: donderdag 8 april 2010 21:45
To: Greg Mirsky; Shahram Davari
Cc: [email-masked]; CCAMP; MPLS-TP ad hoc team; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call
ondraft-ietf-mpls-tp-framework-11

If I have a number of co-routed paths with different PHBs, I can instantiate
a number of L-LSPs, which is a significant amount of state at every hop, or
I can instantiate one E-LSP, which is an N:1 compression in the amount of
state in transit nodes.

 
IMO there is no penalty for supporting E-LSPs and there are measurable
benefits. The analysis is flawed.
 
my 2 cents
D

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Greg Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc: [email-masked]; MPLS-TP ad hoc team; CCAMP; [email-masked];
[email-masked]
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on
draft-ietf-mpls-tp-framework-11

Dear Shahram,

Regards,
Greg

Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we
know traditional transport layers only have one CoS. However E-LSP has
multiple CoS, which can reorder packets (I know that the reorder packets
belong to different CoS). Additionally the definition of E-LSP OAM and
performance and protection and availability, etc will be questionable
(because of carrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least
should be discouraged.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa
Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked];
CCAMP
Subject: [PWE3] short working group last call on
draft-ietf-mpls-tp-framework-11

All,

/Loa
--

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 09:39:52 +0200

Curtis,

I agree that FM OAM must run at the highest priority within an LSP.

However, PM OAM must run at the priority it is measuring.

Italo

> On Behalf Of Curtis Villamizar
> Sent: venerdì 9 aprile 2010 6.30
> To: Shahram Davari
> Cc: MPLS-TP ad hoc team; [email-masked]; CCAMP; 
> [email-masked]; [email-masked]
> Subject: Re: [CCAMP] [mpls] [PWE3] short working group last 
> call ondraft-ietf-mpls-tp-framework-11
> 
> 
> In message 
> <[email-masked]
> d.broadcom.com>
> "Shahram Davari" writes:
> >  
> > Hi John,
> >  
> If there were multiple priorities on an LSP the OAM should be 
> at a high priority.  For example for CS service (the old IP 
> prec) CS6 is normally used for control traffic.  If OAM 
> failed for CS6 the link is down.  If OAM fails for CS0 the 
> link may just be oversubscribed and contested but CS0 is 
> defined as the best effort (BE) service.
> 
> A provider may choose to do this.  For example, if VOIP ran 
> at CS4 and worked fine and web and email was runnig on CS0, 
> phone would work and web would be slow.  If a natural 
> disaster took out 3/4 of the network capacity, then having 
> working phone and slow web and maybe unworkable web streaming 
> video might be better than prohibiting oversubscription and 
> having no service at all.
> 
> Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Apr 2010 09:59:04 +0200

Curtis,

> If there were multiple priorities on an LSP the OAM should be at a high
priority.  

This is the approach taken in Y.1731 for Ethernet OAM.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: vrijdag 9 april 2010 6:30
To: Shahram Davari
Cc: MPLS-TP ad hoc team; [email-masked]; CCAMP; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call
on draft-ietf-mpls-tp-framework-11

In message
<[email-masked]
> the definition of availability for such E-LSP?

If there were multiple priorities on an LSP the OAM should be at a high
priority.  For example for CS service (the old IP prec) CS6 is normally used
for control traffic.  If OAM failed for CS6 the link is down.  If OAM fails
for CS0 the link may just be oversubscribed and contested but CS0 is defined
as the best effort (BE) service.

A provider may choose to do this.  For example, if VOIP ran at CS4 and
worked fine and web and email was runnig on CS0, phone would work and web
would be slow.  If a natural disaster took out 3/4 of the network capacity,
then having working phone and slow web and maybe unworkable web streaming
video might be better than prohibiting oversubscription and having no
service at all.

Curtis
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Apr 2010 10:50:32 +0200

Performance monitoring for multiple CoS connections has been specified in
Y.1731 as follows:

1) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for 
   **one (default: highest)** CoS level in the connection
   [also Degraded (DEG) defect has been defined for this highest CoS level]

2) on-demand frame loss monitoring and frame delay (delay variation)
monitoring
   for any CoS level; this on-demand monitoring does not provide
ES/SES/BBE/UAT
   results, it provides just an event result

MEF has requested to extend the Y.1731 performance monitoring with:

A) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for 
   **every** CoS level in the connection

B) pro-active PM (i.e. 15 minute/24 hour reports) for frame delay
   (delay variation) monitoring for **every** CoS level in the connection

C) introduce pro-active and on-demand synthetic frame loss monitoring for 
   mp2mp/rmp connections for every CoS level in the connection

Q.9/15 and Q.10/15 are analysing the complexity of this extension at the
moment.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of BUSI ITALO
Sent: vrijdag 9 april 2010 9:24
To: Shahram Davari; Loa Andersson; [email-masked]; [email-masked]; MPLS-TP
ad hoc team; [email-masked]; CCAMP
Subject: Re: [mpls-tp] [mpls] [PWE3] short working group last call
ondraft-ietf-mpls-tp-framework-11

Shahram,

> As we know traditional transport layers only have one CoS.

> Additionally the definition of E-LSP OAM and performance and 
> protection and availability, etc will be questionable (because of 
> carrying multiple CoS).

I agree that performance monitoring for multi-CoS connections (e.g., E-LSP)
is not trivial. We have exactly the same issue with Ethernet performance
monitoring.

In principle I think that a solution can be defined but I am spending too
much time on mpls-tp standardization so I had not time to monitor the status
of this work within Q14/15.

I do not see any issue with fault monitoring of multi-CoS connections as
faults are not per-CoS but per-connection.

Italo

P.S. Please note my new email address, [email-masked],
effective since 1 November 2009.

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Shahram Davari
> To: Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc 
> team; [email-masked]; CCAMP
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. 
> As we know traditional transport layers only have one CoS. However 
> E-LSP has multiple CoS, which can reorder packets (I know that the 
> reorder packets belong to different CoS). Additionally the definition 
> of E-LSP OAM and performance and protection and availability, etc will 
> this is to start a short working group last call on "A Framework for

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 10 Apr 2010 23:43:14 -0400

> However, PM OAM must run at the priority it is measuring.

Italo,

It would be best if the documents allowed FM to be run at one
priority.  This should be constrained (at least with a SHOULD) to be
the lowest priority for which congestion cannot occur by virtue of the
SLA, the resource reservations, and policing, or a priority higher
than traffic if all traffic is not policed.  PM should be allowed to
be run at any priority, including run at multiple priorities.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 11 Apr 2010 00:50:01 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
>  
> Dear Italo, if we consider Link Bundle (RFC 4201) then it is possible
> that some CoS flows are being mapped to a different component
> links. In this case per CoS FM is quite necessary.
>  
> Regards,
> Greg

Greg,

That would be a broken implementation.  The AF service occupies 3 TC
values and is supposed to remain in order.

There is no document that suggests this behaviour.

Curtis

> > PM tools (as already documented in the OAM frameworkd draft), is actually=
>  an
> > overdesign for FM tools.
> >
> > *Sent:* gioved=EC 8 aprile 2010 21.45
> > switched (although there would be 'n' signal fail indications internally =
> to
> > takes 'n' times the flows to be instumented like 'n' L-LSPs so what????  =
> I
> > appreciate that the ability to generate per PHB flows may be undesirable =
> for
> > network. Though the document is about the Transport Profile, references t=
> o
> > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <[email-masked]>wrot=
> e:
> >
> >> Hi Loa,
> >>
> >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. A=
> s
> >> we know traditional transport layers only have one CoS. However E-LSP ha=
> s
> --0016e640918a65a9f00483c8d1cb
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>  
> Dear Italo,<br>if we consider Link Bundle (RFC 4201) then it is possible th=
> at some CoS flows are=A0 being mapped to a different component links. In th=
> is case per CoS FM is quite necessary.<br><br>Regards,<br>Greg<br><br><div =
> class=3D"gmail_quote">
> On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO <span dir=3D"ltr">&lt;<a href=
> =3D"mailto:[email-masked]">[email-masked]</a>=
> &gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
> t 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
> ex;">
>  
>  
>  
>  
> <div>
> <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" fa=
> ce=3D"Arial">I think that running OAM flows per-PHB, while very much=20
> appropriate for PM tools (as already documented in the OAM frameworkd draft=
> ), is=20
> actually an overdesign for FM tools.</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" fa=
> ce=3D"Arial"></font></span>=A0</div>
> <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" fa=
> ce=3D"Arial">Misconnections and failures are per-LSP and not=20
> per-PHB.</font></span></div><div class=3D"im">
> <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" fa=
> ce=3D"Arial"></font></span>=A0</div>
> <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" fa=
> ce=3D"Arial">Italo</font></span></div><br>
> <p><font size=3D"2">P.S. Please note my new email address,=20
> <a href=3D"mailto:[email-masked]" target=3D"_blank">Italo.Bu=
> [email-masked]</a>, effective since 1 November 2009.<br></font></p>
> <div>=A0</div><br>
> </div><blockquote style=3D"padding-left: 5px; margin-left: 5px; border-left=
> : 2px solid rgb(0, 0, 255); margin-right: 0px;">
>   <div dir=3D"ltr" align=3D"left" lang=3D"en-us">
>   <hr>
>   <font size=3D"2" face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:ccamp-bou=
> [email-masked]" target=3D"_blank">[email-masked]</a>=20
>   [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ccamp=
> [email-masked]</a>] <b>On Behalf Of </b>David Allan=20
>   I<br><b>Sent:</b> gioved=EC 8 aprile 2010 21.45<br><b>To:</b> Greg Mirsky=
> ;=20
>   Shahram Davari<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_=
> blank">[email-masked]</a>; CCAMP; MPLS-TP ad hoc team;=20
>   <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>; <a =
> href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=
> <b>Subject:</b> Re: [CCAMP] [mpls] [PWE3]=20
>   short working group last callon=20
>   draft-ietf-mpls-tp-framework-11<br></font><br></div><div><div></div><div =
> class=3D"h5">
>   <div></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">I&#39;m not quite following this=20
>   argument....</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial"></font></span>=A0</div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">If I have a number of co-routed paths with different=20
>   PHBs, I can instantiate a number of L-LSPs, which is a significant amount=
>  of=20
>   state at every hop, or I can instantiate=A0one E-LSP, which is an N:1=20
>   compression in the amount of state in transit nodes.</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial"></font></span>=A0</div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">The only wrinkle is all PHBs of an E-LSP fate share. But=20
>   then if I was protecting=A0the L-LSP or the E-LSP version=A0I&#39;d have=
> =20
>   another &#39;n&#39; L-LSPs or another E-LSP, and if they were co-routed, =
> the majority=20
>   of failure cases (link cuts) would result in a loud clang as many=20
>   L-LSPs=A0vs. one E-LSP was switched (although there would be &#39;n&#39; =
> signal=20
>   fail indications internally to contend with).=A0Overall, it sounds to me=
> =20
>   like an E-LSP may be a bit faster there....</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial"></font></span>=A0</div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">The actual OAM load to instrument them equally is the=20
>   same. If an E-LSP takes &#39;n&#39; times the flows to be instumented lik=
> e &#39;n&#39; L-LSPs=20
>   so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20
>   flows may be undesirable for some, but that does not make it a bad=20
>   idea.</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial"></font></span>=A0</div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">IMO there is no penalty for supporting E-LSPs and there=20
>   are measurable benefits. The analysis is flawed.</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial"></font></span>=A0</div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">my 2 cents</font></span></div>
>   <div dir=3D"ltr" align=3D"left"><span><font size=3D"2" color=3D"#0000ff" =
> face=3D"Arial">D</font></span></div><br>
>   <div dir=3D"ltr" align=3D"left" lang=3D"en-us">
>   <hr>
>   <font size=3D"2" face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:ccamp-bou=
> [email-masked]" target=3D"_blank">[email-masked]</a>=20
>   [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ccamp=
> [email-masked]</a>] <b>On Behalf Of </b>Greg=20
>   Mirsky<br><b>Sent:</b> Thursday, April 08, 2010 3:31 PM<br><b>To:</b> Sha=
> hram=20
>   Davari<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">m=
> [email-masked]</a>; MPLS-TP ad hoc team; CCAMP;=20
>   <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=
> >; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=
> <b>Subject:</b> Re: [CCAMP] [mpls] [PWE3]=20
>   short working group last call on=20
>   draft-ietf-mpls-tp-framework-11<br></font><br></div>
>   <div></div>Dear Shahram,<br>I share your concern regarding applicability =
> of=20
>   E-LSP in packet transport network. Though the document is about the Trans=
> port=20
>   Profile, references to MPLS-TP as packet transport network technology bee=
> n=20
>   changed recently. Now MPLS-TP is referred as &quot;packet network&quot;. =
> It is my=20
>   understanding that applicability of MPLS-TP functionality, features and=
> =20
>   capabilities to the packet transport network will be decided later,=20
>   separately.<br>Regarding classes of service in the transport. Neil Harris=
> on=20
>   pointed several times that a connection, transport path cannot have multi=
> ple=20
>   classes, otherwise it leads to significant increased complexity of OAM, w=
> hich=20
>   has to be (SHOULD) per Class of Service per=20
>   E-LSP.<br><br>Regards,<br>Greg<br><br>
>   <div class=3D"gmail_quote">On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davar=
> i <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_b=
> lank">[email-masked]</a>&gt;</span>=20
> wrote:<br>
>   <blockquote class=3D"gmail_quote" style=3D"padding-left: 1ex; margin: 0pt=
>  0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);">Hi=20
>     Loa,<br><br>The draft mentions that both L-LSP and E-LSP are supported =
> in=20
>     MPLS-TP. As we know traditional transport layers only have one CoS. How=
> ever=20
>     E-LSP has multiple CoS, which can reorder packets (I know that the reor=
> der=20
>     packets belong to different CoS). Additionally the definition of E-LSP =
> OAM=20
>     and performance and protection and availability, etc will be questionab=
> le=20
>     (because of carrying multiple CoS).<br><br>Therefore I think E-LSP shou=
> ld=20
>     not be supported in MPLS-TP or at least should be=20
>     discouraged.<br><br>Regards,<br>Shahram<br>
>     <div>
>     <div></div>
>     <div><br>-----Original Message-----<br>From: <a href=3D"mailto:pwe3-bou=
> [email-masked]" target=3D"_blank">[email-masked]</a> [mailto:<a href=
> =3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=
> a>] On Behalf Of=20
>     Loa Andersson<br>Sent: Saturday, April 03, 2010 2:31 AM<br>To: <a href=
> =3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>; <a hre=
> f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>; MPLS-TP ad =
> hoc team; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]<=
> /a>; CCAMP<br>
> Subject: [PWE3]=20
>     short working group last call on=20
>     draft-ietf-mpls-tp-framework-11<br><br>All,<br><br>this is to start a s=
> hort=20
>     working group last call on &quot;A Framework<br>for MPLS in Transport N=
> etworks&quot;=20
>     (draft-ietf-mpls-tp-framework-11).<br><br>Please note that this wg last=
>  call=20
>     is limited to verify that comments<br>raised during the orevious workin=
> g=20
>     group last call and reviews have<br>been correctly addressed.<br><br>Pl=
> ease=20
>     sen comments to the mpls-tp mailing list on April 17th,=20
>     the<br>latest.<br><br>/Loa<br>--<br><br><br>Loa Andersson =A0 =A0=20
>     =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20
>     <a href=3D"mailto:[email-masked]" target=3D"_blank">loa.and=
> [email-masked]</a><br>Sr=20
>     Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"mailto=
> :[email-masked]" target=3D"_blank">[email-masked]</a><br>Ericsson Inc =A0 =A0 =A0=20
>     =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20
>     +46 10 717 52 13<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
>     =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20
>     =A0 =A0 =A0 =A0+46 767 72 92=20
>     13<br>_______________________________________________<br>pwe3 mailing=
> =20
>     list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
> g</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_=
> blank">https://www.ietf.org/mailman/listinfo/pwe3</a><br><br><br></div></di=
> v>_______________________________________________<br>
> mpls=20
>     mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">mpls=
> @ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/mpls" tar=
> get=3D"_blank">https://www.ietf.org/mailman/listinfo/mpls</a><br></blockquo=
> te>
> </div><br></div></div></blockquote></div>
> </blockquote></div><br>
>  
> --0016e640918a65a9f00483c8d1cb--
>  
> --===============1523831359==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>  
> --===============1523831359==--

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 11 Apr 2010 09:03:45 +0100

In Loa's original mail he says "Please send comments to the mpls-tp mailing list..."

Please can we continue this discussion on ONLY that list ([email-masked]).

Thanks

Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 11 Apr 2010 01:11:31 -0700

On Sat, Apr 10, 2010 at 9:50 PM, Curtis Villamizar <[email-masked]> wrote:

>
> In message <[email-masked]
> >
> Greg Mirsky writes:
> >
> >
> Hi Curtis,
if label scope is not covered by the special case described in the RFC and
there's no component link with sufficient resource, the LSP would not be
set. But I don't find wording in the document that discourages such behavior
if scope of the label is requested to be across all component links. In my
view it is allowed, as local policy, even though not in all cases.
On another thread you've mentioned implementations that advertise the
Maximum LSP B/W in the way different from my reading of the RFC 4201. It
would benefit us all if we discuss and describe this behavior and its
applicability to MPLS-TP.

Regards,
Greg

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 01:42:32 -0400

In message <[email-masked]>
Greg Mirsky writes:
> if label scope is not covered by the special case described in the RFC
> and there's no component link with sufficient resource, the LSP would
> not be set. But I don't find wording in the document that discourages
> such behavior if scope of the label is requested to be across all
> component links. In my view it is allowed, as local policy, even
> though not in all cases.  On another thread you've mentioned
> implementations that advertise the Maximum LSP B/W in the way
> different from my reading of the RFC 4201. It would benefit us all if
> we discuss and describe this behavior and its applicability to
> MPLS-TP.
>  
> Regards,
> Greg

Greg,

In a nutshell it is one way to do LAG without Ethernet.  For MPLS it
behaves the same as LAG, uses the same hardware to load balance, etc.

Curtis