Subject: RE: PWE3 new WG items? PW QoS

From: "Proch, Daniel" <[email-masked]>
Date: Thu, 19 Feb 2004 09:20:54 -0500

>>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
>>
>>

dan -
Maybe I misunderstand the problem, but it seems that RSVP-TE is not
necessary.  Signaling PW QoS is separate from PSN tunnel QoS.  The problem
that I see is how to inform the other side of a pseudo wire what QoS
considerations should be taken the connection.  It is an implementation
specific task for the PE router to determine how to multiplex the PW into a
PSN tunnel based on the requested QoS.

LDP already exists for PW label distribution and the any LDP conversation is
targeted to the directly to the other PE router (invisible to core).
Therefore LDP can be extended to add QoS signaling for the PW as is.  

If RSVP-TE was already used for PW setup, I'd agree that it could also be
used to signal QoS, but absent that, why would it be used in this
application?  For example, in the ATM Forum ATM/MPLS interworking specs PNNI
is used for PW label distribution for ATM VCs and therefore PW QoS is
supported as is.

dan proch

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 19 Feb 2004 09:35:03 -0500

> -----Original Message-----
> From: Proch, Daniel [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 9:21 AM
> To: 'Rahul Aggarwal'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [PWE3] PWE3 new WG items? PW QoS
> 
> 

I would agree that if QoS were the only problem that needs to be solved it could be acceptable to carry QoS information in the LDP messages that are used for PW setup (albeit that it is somewhat ugly since it makes LDP look like CR-LDP which has been depreciated).

However, there are other issues that need to be solved. Several people on this mailing list suggested that we need to address PW stitching. It seems to me that stitching of PWs requires a signaling protocol that establishes a multi-hop PW through switches that switch based on the PW label. RSVP is in my view the only reasonable solution.

Hence, if we don't look at one problem at a time, but at the entire problem space, I think we need to adopt RSVP as a way to establish PWs. It would solve the problems of both QoS and stitching.

Peter

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 19 Feb 2004 10:52:56 -0500

If one was to map one PW per transport LSP,
one does not need RSVP signaling for PW QOS....:-)

I remember a debate at IETF where a group of people 
were concerned about scaling of RSVP's use 
for LSP signaling. Well, PWs are multi magnitude
higher order than transport LSPs.

Also, isn't direction an issue?
Target PE (tail end) tells the source PE (head end)
about his local AC's QOS requirements. Source PE (head-end)
then selects an appropriate transport tunnel to target PE (tail-end).
If I remember correctly, in RSVP-TE the head-end specifies
the QOS requirement (which tail-end can adjust in RESV).

/himanshu

> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 10:51 AM
> To: Busschbach, Peter B (Peter)
> Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; [email-masked];
> Shah, Himanshu; [email-masked]
> Subject: Re: [PWE3] PWE3 new WG items? PW QoS
> 
> 
> Busschbach, Peter B (Peter) wrote:
> 
> [snip]
> 
> >I would agree that if QoS were the only problem that needs 
> to be solved it could be acceptable to carry QoS information 
> in the LDP messages that are used for PW setup (albeit that 
> it is somewhat ugly since it makes LDP look like CR-LDP which 
> has been depreciated).
> >
> >However, there are other issues that need to be solved. 
> Several people on this mailing list suggested that we need to 
> address PW stitching. It seems to me that stitching of PWs 
> requires a signaling protocol that establishes a multi-hop PW 
> through switches that switch based on the PW label. RSVP is 
> in my view the only reasonable solution.
> >
> >Hence, if we don't look at one problem at a time, but at the 
> entire problem space, I think we need to adopt RSVP as a way 
> to establish PWs. It would solve the problems of both QoS and 
> stitching.
> >
> >Peter
> >
> >  
> >
> Peter,
> It is possible ( I already know of one implementation ) to select an 
> RSVP LSP to transport a single PW.
> That does not change the protocol , and does carry QoS information 
> needed by the PSN. It also achieves another property that as it turns 
> out is quite useful in practice: explicit routing of the PW 
> across the 
> PSN. ( this is for TE , but also other reasons like avoiding 
> shared PSN 
> failure modes )
> 
> Luca
> 
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >  
> >
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 19 Feb 2004 12:27:37 -0500

Also note that QOS information exchange
is not necessarily restricted to TE-LSP
(Eric made that point while back)

The Receiving PE may use this info only 
to select the right Policer for local AC.

/himanshu

> From: Shah, Himanshu 
> Sent: Thursday, February 19, 2004 10:53 AM
> To: 'Luca Martini'; Busschbach, Peter B (Peter)

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 20 Feb 2004 10:15:40 -0500

> Actually PW stitching can be implemented entirely using 
> existing pseudowire 
> signaling procedures (using LDP or L2TP) without any new 
> protocol or extension. 
>   The signaling protocol is not an issue.

Hi Wei,

I respectfully disagree. The fact that we have a signaling protocol to set up single PW segments doesn't mean that it is clear how to establish multi-segment PWs. E.g.

- Are segments set up in a random order or is there a need for a certain sequence of message?

- Is it necessary to use the same values for Interface Parameters on each segment?

- Is VCCV used on single segments or end-to-end? If the latter, do intermediate points monitor or do they blindly forward the packets?

- In case a segment goes down, are alarm signals sent to the end-points of the multi-segment PW or is the error handled locally?

All these, and probably more, need to be specified. On the other hand, if we decide that a multi-segment PW is essentially an LSP that can be set up with RSVP-TE, the RSVP-TE spec provides most of the answers.

Peter

> 
> With regard to PW stitching, this working group probably 
> should focus on the 
> operational issues with regard to PW stitching, such as 
> whether Attachment 
> Circuit interworking is needed at the stitching point, how to 
> interwork between 
> different PSN types, sequencing, multi-hop VCCV, Inter-AS 
> considerations and 
> other network management subjects.
> 
> ---Wei
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 23 Feb 2004 04:12:48 -0500

> From: Wei Luo [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 6:20 PM
> [email-masked]; [email-masked]
> Hi Peter,
> Actually we are in agreement on what specific issues need to 
> be resolved for PW 
> stitching.  We literally listed the same stuff.  What we 
> might disagree is how 
> to solve these problems.
> 
> You seem to be advocating that RSVP is the cure for all these 
> issues, 

To be precise: I am advocating that RSVP is *one* cure for all these problems, with the nice property that it exists today. Of course we can define another solution to PW-splicing from scratch, but I think it is preferable to use an existing protocol.

Otherwise, I agree with you that we need to define the scope of the problem before we can decide on a solution.

> but I am 
> more inclined to have the working group define the scope of 
> the problems first, 
> and then we could decide whether they can be solved by 
> implementation specific 
> mechanisms or a new protocol procedure is necessary.  The 
> current protocol 
> procedures are sufficient for multi-semgent PWs signaling in 
> the sense that they 
> can handle end-to-end setup, teardown, notification, and etc. 
> with proper 
> implementation at the stitching points.
> 
> ---Wei
> 
> > I respectfully disagree. The fact that we have a signaling 
> protocol to set up single PW segments doesn't mean that it is 
> clear how to establish multi-segment PWs. E.g.
> > 
> > - Is VCCV used on single segments or end-to-end? If the 
> latter, do intermediate points monitor or do they blindly 
> forward the packets?
> > 
> > - In case a segment goes down, are alarm signals sent to 
> the end-points of the multi-segment PW or is the error 
> handled locally?
> > 
> > All these, and probably more, need to be specified. On the 
> other hand, if we decide that a multi-segment PW is 
> essentially an LSP that can be set up with RSVP-TE, the 
> RSVP-TE spec provides most of the answers.
> > 
> > Peter
> > 
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 23 Feb 2004 04:26:19 -0500

Peter>- Are segments set up in a random order or is there a need 
> for a certain sequence of message?
> >  
> >
Scott> For scaling and robustness you can't require a certain order of setup.

Scott,

Assume one wants to set up a multi-segment from A via B and C to D to carry ATM traffic. Suppose that the segment between B and C is set up independently from the other two segments. Then it is possible that B indicates to C that it accepts a maximum number of ATM cells per frame equal to N1. Subsequently, B could learn from A that A accepts a maximum number of ATM cells per frame equal to N2. If N2 is smaller than N1, there is a problem. B might have to repackage frames it receives from C to make sure it doesn't exceed N2 cells in the frames it forwards to A.

Based on this example, it seems obvious to me that B has to receive a PW setup message from A before it can forward it to C and C has to receive a setup message from B before it can forward it to D. In other words, there is a clear order.

Peter

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 23 Feb 2004 15:48:49 -0500

Peter> Assume one wants to set up a multi-segment from A via B and 
> C to D to carry ATM traffic. Suppose that the segment between 
> B and C is set up independently from the other two segments. 
> Then it is possible that B indicates to C that it accepts a 
> maximum number of ATM cells per frame equal to N1. 
> Subsequently, B could learn from A that A accepts a maximum 
> number of ATM cells per frame equal to N2. If N2 is smaller 
> than N1, there is a problem. B might have to repackage frames 
> it receives from C to make sure it doesn't exceed N2 cells in 
> the frames it forwards to A.
> 
> Based on this example, it seems obvious to me that B has to 
> receive a PW setup message from A before it can forward it to 
> C and C has to receive a setup message from B before it can 
> forward it to D. In other words, there is a clear order.
> 
Wei> Hi Peter,
> 
> Agree with your observation.  Even though the ordered setup 
> is a sensible 
> approach and makes life easier to establish a multi-segment 
> pseudowire, it's 
> still up to the stitching nodes, B and C in this case, to 
> decide what the 
> aggragated events should be to trigger its signaling.  For 
> example, they need 
> other resources to get ready before start signaling and they can wait 
> indefinitely before start signaling.
> 

Wei,

This is perhaps another example where it makes sense to describe the problem to be solved before discussing solutions.

In my view of the world, if you need a multi-segment PW from A via B and C to D, you can only achieve your goal if all four nodes are ready. I don't see why it makes sense to set up the segment between B and C if A or D are not ready yet.

I could even go further: I would argue that node B doesn't even know that it is in the path from A to D, until it receives a setup message from A. To protect against network failures, node A should be able to decide on the best route to destination D and node B might not lie on that route.

But again, let's formulate the problem first.

Peter

> Therefore, the ordered setup seems to be more of an 
> implementation specific 
> issue for the stitching nodes rather than an item to be standardized.
> 
> ---Wei
> 
> > 
> > Peter 
> >