Subject: PWE3 new WG items?

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Feb 2004 18:25:09 +0000

As we mentioned at last IETF we need to start the
process of re-chartering the PWE3 WG.

What do WG members think we need to work on next?

- Stewart

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 13 Feb 2004 13:50:15 -0500

QOS stuff of course... :-)

We submitted PWE3 Control protocol extension to 
exchange capabilities as a way to add more stuff
and to negotiate. I think QOS for PW is important.

Others are,
1) IP PW
2) Multiprotocol PW
3) Inter-carrier PW (PW switching?)
4) PW bundling
5) PW fault tolerence
6) PW congestion (Eric Rosen already has a proposal on this)

/himanshu

PS. assuming that OAM is ongoing and underway already.

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 1:25 PM
> To: [email-masked]
> Subject: [PWE3] PWE3 new WG items?
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Chris Metz <[email-masked]>
Date: Fri, 13 Feb 2004 11:01:04 -0800

>What do WG members think we need to work on next?

PW Stitching - that is the concatenation of two or more PW segments forming 
a multi-segment/multi-hop PW.

Cheers ...

---

From: [email-masked]
Date: Tue, 17 Feb 2004 18:44:13 -0000

Folks,

> and to negotiate. I think QOS for PW is important.

An observation/fact: A PW acts as a client to a server layer (be it MPLS, IP or whatever) and as a result the QoS that can be provided by a PW cannot be better than the QoS provided by the server layer used by the PW.

My comments:
1) Assuming that the QoS in the available server layers (e.g EXP bits/DiffServ for the MPLS/IP server layers) is adequate (and it could be argued that it isn't) then given that a PW is basically a MPLS LSP with sequence number support, why does PW QoS need its own specification?  Why can't a PW use the same QoS mechanisms as MPLS LSPs?

For example, why would a service provider deploying PWs over a MPLS core want to use two different but interacting QoS mechanisms (one for PWs, one for MPLS LSPs) and add significant additional fault conditions/complexity/opex to their network when they could use the same QoS mechanism for both PWs and MPLS?

2) Assuming that QoS in the available server layers is not adequate then seeing as PW QoS is dependant on the server layer QoS, shouldn't the problem of specifying adequate QoS in the available server layers be addressed first?  Once there is adequate QoS in the available server layers then comment (1) above applies.

So either:
QoS for MPLS is adequate and ergo the problem of QoS for PWs has already been addressed.

Or, QoS for MPLS is inadequate and ergo QoS for MPLS should be addressed first and then the problem of QoS for PWs has already been addressed.

Ben

The above is my personal view and does not necessarily reflect the opinion of my employer.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 17 Feb 2004 14:21:28 -0500

Hi Ben,

Lets suppose PE1 and PE2 has PW between them.
When exchanging PW-FEC, PE2 tells PE1 what PW-Label
to use when sending traffic from PE1 to PE2.

With QOS, PE2 also tells PE1, what QOS to use when
sending traffic from PE1 to PE2. In a traffic engineered
mpls core, PE1 would then select a (CAC enabled)transport tunnel
(assuming there is more than one) that suits PW's QOS 
requirement that goes from PE1 to PE2. It is also possible to
create and/or adjust transport tunnel aperture that suits PW's 
QOS requirement.

This is the motivation.

/himanshu

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 1:44 PM
> To: [email-masked]
> Subject: RE: [PWE3] PWE3 new WG items?
> 
> 
> Folks,
> 
> An observation/fact: A PW acts as a client to a server layer 
> (be it MPLS, IP or whatever) and as a result the QoS that can 
> be provided by a PW cannot be better than the QoS provided by 
> the server layer used by the PW.
> 
> My comments:
> 1) Assuming that the QoS in the available server layers (e.g 
> EXP bits/DiffServ for the MPLS/IP server layers) is adequate 
> (and it could be argued that it isn't) then given that a PW 
> is basically a MPLS LSP with sequence number support, why 
> does PW QoS need its own specification?  Why can't a PW use 
> the same QoS mechanisms as MPLS LSPs?
> 
> For example, why would a service provider deploying PWs over 
> a MPLS core want to use two different but interacting QoS 
> mechanisms (one for PWs, one for MPLS LSPs) and add 
> significant additional fault conditions/complexity/opex to 
> their network when they could use the same QoS mechanism for 
> both PWs and MPLS?
> 
> 2) Assuming that QoS in the available server layers is not 
> adequate then seeing as PW QoS is dependant on the server 
> layer QoS, shouldn't the problem of specifying adequate QoS 
> in the available server layers be addressed first?  Once 
> there is adequate QoS in the available server layers then 
> comment (1) above applies.
> 
> So either:
> Or, QoS for MPLS is inadequate and ergo QoS for MPLS should 
> be addressed first and then the problem of QoS for PWs has 
> already been addressed.
> 
> Ben
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 17 Feb 2004 14:26:45 -0500

> the same QoS mechanisms as MPLS LSPs?

Benjamin, 

I think the issue is not that there is a need for a PW specific QoS mechanism. As you observe correctly, QoS guarantees must be given to the PSN tunnel over which the PW rides. The QoS parameters in the PW Control messages serve merely to exchange information between PEs.

E.g. suppose PE1 sets up a PW  triggered by an event on one of its Attachment Circuits. Based on the nature of the event, PE1 may decide that the underlying PSN Tunnel needs to provide specific QoS guarantees. However, PE2 may not be aware of that, unless it is told by PE1. Hence, the need for QoS parameters in the PW Control messages.

Peter

---

From: [email-masked]
Date: Tue, 17 Feb 2004 22:02:57 -0000

So what you are proposing is the problem of signalling the QoS parameters that should be associated with a given PW.  As PW signalling is based on MPLS signalling, I believe that the signalling of QoS parameters is a generic MPLS problem and not one specific to PWs.  In which case it is a problem that should be addressed by the MPLS WG and not the PWE WG.

Ben

-----Original Message-----
From:	Shah, Himanshu [mailto:[email-masked]]
Sent:	Tue 17-Feb-04 19:21
To:	Niven-Jenkins,B,Ben,XGH5 R; [email-masked]
Cc:	
Subject:	RE: [PWE3] PWE3 new WG items?
Hi Ben,

This is the motivation.

/himanshu

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 17 Feb 2004 17:18:14 -0500

Signaling of the QOS parameters that is specific to 
a given PW-FEC falls within the charter of PWE3 as
it is an attribute of a PW-FEC.

This is my understanding.

/himanshu

> Sent: Tuesday, February 17, 2004 5:03 PM
> To: Shah, Himanshu; [email-masked]
> So what you are proposing is the problem of signalling the 
> QoS parameters that should be associated with a given PW.  As 
> PW signalling is based on MPLS signalling, I believe that the 
> signalling of QoS parameters is a generic MPLS problem and 
> not one specific to PWs.  In which case it is a problem that 
> should be addressed by the MPLS WG and not the PWE WG.
> 
> Ben
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 17 Feb 2004 17:31:19 -0500

more correctly -  "... attribute of an (egress) AC"

> From: Shah, Himanshu 
> Sent: Tuesday, February 17, 2004 5:18 PM
> To: [email-masked]'; [email-masked]

---

From: [email-masked]
Date: Wed, 18 Feb 2004 14:38:29 -0000

> This is my understanding.

Well, I would say that as:

1) PWs are basically LSPs (and therefore they inherit all the properties of a LSP and add their own PW specific properties)

2) PW signalling is an extension to LSP signalling (and therefore it inherits all the properties of LSP signalling and adds its own PW specific properties)

The problem of signalling QoS parameters is not a PW specific problem and therefore should not be addressed by the PWE3 WG.

If the QoS signalling mechanisms that exist already (e.g. CR-LDP) are adequate then why not re-use them for PWs because PWs should automatically inherit any traffic parameters signalled at the same time as the PW-FEC?  If the existing QoS signalling mechanisms are not adequate then fix them but in such a way that they can be used for MPLS LSPs and PWs.

IMO defining PW specific QoS signalling just limits the amount of functional convergence/re-use that can be achieved and therefore increases the complexity of any solution (and by implication increases the opex for any service provider wishing to deploy that solution).

Unfortunately CR-LDP has been deprecated so the opportunities for functional convergence/re-use are more limited and it looks like re-inventing the wheel[1] is one possible (although I would consider it to be an undesirable) solution :-(

Ben

[1] either the PW signalling wheel (e.g. add PW signalling to RSVP-TE) or the LDP QoS wheel (e.g. add QoS signalling to LDP).

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 18 Feb 2004 10:02:48 -0500

Ben,

I agree that the PWE3 WG could have decided to treat PWs as LSPs (which currently is not true) and to use RSVP as the protocol for PW set up. I have argued on this mailing list that that would have been a better approach, e.g. because it would provide a solution for the creation of multi-hop PWs, preferable to the splicing approach that is now on the table. Similarly, RSVP would provide an immediate solution for signaling QoS parameters.

I am in favor of adopting RSVP as a valid protocol for PW set up. However, as long as that is not accepted by the WG, there is a need to address QoS for PWs in a different way. You can call it re-inventing the wheel, but it needs to be done.

Peter

> Sent: Wednesday, February 18, 2004 9:38 AM
> To: [email-masked]; [email-masked]
> 1) PWs are basically LSPs (and therefore they inherit all the 
> properties of a LSP and add their own PW specific properties)
> 
> 2) PW signalling is an extension to LSP signalling (and 
> therefore it inherits all the properties of LSP signalling 
> and adds its own PW specific properties)
> 
> The problem of signalling QoS parameters is not a PW specific 
> problem and therefore should not be addressed by the PWE3 WG.
> 
> If the QoS signalling mechanisms that exist already (e.g. 
> CR-LDP) are adequate then why not re-use them for PWs because 
> PWs should automatically inherit any traffic parameters 
> signalled at the same time as the PW-FEC?  If the existing 
> QoS signalling mechanisms are not adequate then fix them but 
> in such a way that they can be used for MPLS LSPs and PWs.
> 
> IMO defining PW specific QoS signalling just limits the 
> amount of functional convergence/re-use that can be achieved 
> and therefore increases the complexity of any solution (and 
> by implication increases the opex for any service provider 
> wishing to deploy that solution).
> 
> Unfortunately CR-LDP has been deprecated so the opportunities 
> for functional convergence/re-use are more limited and it 
> looks like re-inventing the wheel[1] is one possible 
> (although I would consider it to be an undesirable) solution :-(
> 
> Ben
> 
> [1] either the PW signalling wheel (e.g. add PW signalling to 
> RSVP-TE) or the LDP QoS wheel (e.g. add QoS signalling to LDP).
> 
> 
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 18 Feb 2004 10:14:13 -0500

Ditto.

Understand your concern but like Peter says
we can not scrap everything and start
from the scratch.

/himanshu

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Wednesday, February 18, 2004 10:03 AM
> To: [email-masked]'; Shah, Himanshu; [email-masked]
> I agree that the PWE3 WG could have decided to treat PWs as 
> LSPs (which currently is not true) and to use RSVP as the 
> protocol for PW set up. I have argued on this mailing list 
> that that would have been a better approach, e.g. because it 
> would provide a solution for the creation of multi-hop PWs, 
> preferable to the splicing approach that is now on the table. 
> Similarly, RSVP would provide an immediate solution for 
> signaling QoS parameters.
> 
> I am in favor of adopting RSVP as a valid protocol for PW set 
> up. However, as long as that is not accepted by the WG, there 
> is a need to address QoS for PWs in a different way. You can 
> call it re-inventing the wheel, but it needs to be done.
> 
> Peter
>

---

From: [email-masked]
Date: Wed, 18 Feb 2004 15:23:15 -0000

Peter,

> protocol for PW set up.

The PWE3 WG may have decided not to treat PWs as LSPs but it doesn't (IMO) avoid the fact that a PW *always* uses a LSP for transport.  AIUI a PW consists of two parts:

1) An adaptation function that describes how to encapsulate a client layer (e.g. Ethernet) onto a server layer (e.g. MPLS). This is defined by the PWE WG.

2) A LSP (let's call it the 'PW LSP') that transports the above adaptation function (and its client payload) across a network.  This is defined by the MPLS WG with some PW specific extensions (e.g. PW FEC)

For scalability etc. a second LSP (let's call it the 'transport LSP') is also used and a 2 level LSP hierarchy/stack is created with the inner LSP being the 'PW LSP' (which is a single hop) and the outer LSP being the 'transport LSP'.

Now my argument is that any QoS parameters associated with a PW are in actual fact associated with the 'PW LSP' and not the adaptation function.  Therefore any QoS parameters/signalling that are associated with a PW are in actual fact associated with the 'PW LSP'.

Therefore I believe that the signalling of PW QoS parameters is the same problem as the signalling of LSP QoS parameters and therefore does not fall under the PWE3 WG.

---

From: [email-masked]
Date: Wed, 18 Feb 2004 15:38:56 -0000

> we can not scrap everything and start

Which is better:

1) To admit a mistake may have been made and attempt to resolve it.
2) To refuse to admit a mistake may have been made and attempt to work around it whilst adding extra complexity/opex in the process.

I'm not suggesting people start over (although that is obviously one possible approach), however as I see it:

1) The problem of signalling PW QoS is actually the more general problem of signalling MPLS LSP QoS and therefore comes under the remit of the MPLS WG.

2) The MPLS WG has already looked at constraint based LSP setup (with QoS being one posslbe constraint) and developed CR-LDP and RSVP-TE as a result. 

Therefore IMO the signalling of PW QoS has one of two solutions:

1) Add PW signalling to CR-LDP (although this would be the easiest solution, CR-LDP has been deprecated).

2) Add PW signalling to RSVP-TE.

Neither of which require PW specific QoS signalling mechanism because adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex.

Ben

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Feb 2004 10:50:03 -0500

> a PW *always* uses a LSP for transport

No it doesn't. 

But I think that's irrelevant anyway. 

I  think that  all  you're really  saying is  that  the QoS  belongs to  the
transport (the  enclosing LSP or  the L2TPv3 session),  not to the  PW.  (Of
course, it's hard to see through the gibberish of buzz words.) 

The opposite point of  view is that you need to know the  PW QoS in order to
select a transport  LSP or L2TPv3 session properly,  one endpoint might want
to  signal this  to the  other, and  the  PW QoS  might even  impact (or  be
impacted by) some  characteristic of the AC.  I think  this is what Himanshu
was saying, and prima facie it seems right to me.

---

From: [email-masked]
Date: Wed, 18 Feb 2004 15:59:08 -0000

> was saying, and prima facie it seems right to me.  

I agree that you need to know the QoS a PW requires in order to associate it with a transport LSP etc.  However as PW signalling is basically piggybacked onto LSP signalling what is the motivation for a PW specific QoS signalling mechanism (as suggested by Himanshu) when LSP QoS signalling mechanisms already exist?

Ben

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Feb 2004 11:22:56 -0500

> what  is the motivation  for a  PW specific  QoS signalling  mechanism (as
> suggested by Himanshu) when LSP QoS signalling mechanisms already exist?  

Obviously the appropriate mechanisms do not already exist. 

Once we see a  proposal, we'll be able to judge whether  it has more general
applicability to MPLS  than just PWs.  It's possible that  it will (in which
case the MPLS WG  may need to get involved), but it's  also possible that it
won't.

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 18 Feb 2004 17:40:11 +0200

Ben and all,
You may argue that the transport LSP is added for scalability reasons.
However,  you seem to ignore two facts:

1. The PW LSP is *always* a one-hop LSP, so that its label is understood
only
    buy the receiving PE but not by any intermediate LSR. 
2. As a consequence, in a (common) case where the transport LSP exists
    the QoS parameters associated with its specific PW clients MUST be 
    reflected in the transport label stack entries (since only these are
processed
    by the intermediate LSRs).

This means that the QoS problem for MPLS PWs is real: e.g., if your PW
assumes
a certain set of QoS parameters which cannot be supported by the given
transport LSP
between the pair of the PEs, the PW setup SHOULD either fail or result in
setup of a 
new transport LSP which then would be used by the PW.

(Of course this is exactly what Himanshu and Peter say, even if the wording
is different:-).

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Wednesday, February 18, 2004 5:23 PM
> To: [email-masked]
> The PWE3 WG may have decided not to treat PWs as LSPs but it 
> doesn't (IMO) avoid the fact that a PW *always* uses a LSP 
> for transport.  AIUI a PW consists of two parts:
> 
> 1) An adaptation function that describes how to encapsulate a 
> client layer (e.g. Ethernet) onto a server layer (e.g. MPLS). 
> This is defined by the PWE WG.
> 
> 2) A LSP (let's call it the 'PW LSP') that transports the 
> above adaptation function (and its client payload) across a 
> network.  This is defined by the MPLS WG with some PW 
> specific extensions (e.g. PW FEC)
> 
> For scalability etc. a second LSP (let's call it the 
> 'transport LSP') is also used and a 2 level LSP 
> hierarchy/stack is created with the inner LSP being the 'PW 
> LSP' (which is a single hop) and the outer LSP being the 
> 'transport LSP'.
> 
> Now my argument is that any QoS parameters associated with a 
> PW are in actual fact associated with the 'PW LSP' and not 
> the adaptation function.  Therefore any QoS 
> parameters/signalling that are associated with a PW are in 
> actual fact associated with the 'PW LSP'.
> 
> Therefore I believe that the signalling of PW QoS parameters 
> is the same problem as the signalling of LSP QoS parameters 
> and therefore does not fall under the PWE3 WG.
> 
> 
> 
>

---

From: Nick DelRegno <[email-masked]>
Date: Wed, 18 Feb 2004 17:08:52 -0600

A means of signaling/negotiating the QOS associated with a PW would be 
beneficial.  And doable.  We have seen implementations that already support 
two levels of QOS: one aggregate QOS for the PSN tunnel (usually a LSP) and 
discrete QOS for constituent PW Virtual Circuits.  I like this model.

Any transit LSRs in the LSP path with provide QOS on the aggregate LSP 
only, ensuring that the PSN tunnel has the proscribed bandwidth.  The PW 
QOS negotiation would be used at the PE function (traditionally at each end 
of the PW).  However, as we find new ways to apply these tools, the ability 
to signal the VC QOS and bandwidth becomes very interesting.  At some 
point, when we have multi-hop PWs (through stitching or other mechanisms) 
signaling the PW QOS instead of manually provisioning it would be helpful.

Whether we use CR-LDP, RSVP-TE or PW-specific extensions of 
"draft-ietf-pwe3-control-protocol-xx.txt" is immaterial at this point.  I 
agree that this should be a PWE3 WG item, as well as PW stitching and 
hierarchy.

Nick

---

From: "Cui, Yongxin (Yongxin)" <[email-masked]>
Date: Wed, 18 Feb 2004 21:53:39 -0500

Rahul,

If the PW has the QoS requirement and needs to reserve resources inside the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM traffic, how does the LDP with CR work?

For example, I have a PSN tunnel with 10Mbps bandwidth configured. Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth.

Thanks,

Yongxin

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: Thursday, February 19, 2004 10:42 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] PWE3 new WG items?

Hi Ben,

[snip]

> 1) Add PW signalling to CR-LDP (although this would be the easiest 
> solution,
CR-LDP has been deprecated).

> 2) Add PW signalling to RSVP-TE.

For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup:
  - LDP
  - RSVP-TE

Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement.

There is no reason why PWE setup cannot follow a similar model:
  - LDP for PW signaling without QoS
  - RSVP-TE for PW signaling with QoS

rahul

> Neither of which require PW specific QoS signalling mechanism because 
> adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or 
> RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex.
>
>
> Ben
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 19 Feb 2004 07:31:06 +0200

Nick and all,
I also think that PW stitching (a.k.a splicing)
and QoS are relevant new WG items.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Nick DelRegno [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 1:09 AM
> To: [email-masked]
> Subject: Re: [PWE3] PWE3 new WG items?
> 
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 19 Feb 2004 09:09:06 +0200

>   - RSVP-TE for PW signaling with QoS

I agree that we need two models.

But we are not always over MPLS.
Are we going to use RSVP in the pure IP case?
            or is QoS only for MPLS infrastructure?

Y(J)S