Subject: RE: PWE3 new WG items? PW QoS

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 23 Feb 2004 01:46:52 -0800 (PST)

[snip]

>
> we need to define the scope of the problem before we can decide
> on a solution.

That sounds quite reasonable.

rahul

>
>
> > 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
> >
> > Busschbach, Peter B (Peter) wrote:
> > >>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: Stewart Bryant <[email-masked]>
Date: Mon, 23 Feb 2004 10:12:18 +0000

Is there a need for interprovider stiching of PWs?

Presumably if there is, that has implications for our QoS
strategy.

- Stewart

---

From: Wei Luo <[email-masked]>
Date: Mon, 23 Feb 2004 11:34:30 -0800

Busschbach, Peter B (Peter) wrote:
>  
> Peter>- Are segments set up in a random order or is there a need 
> 
> 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.

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.

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 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Scott W Brim <[email-masked]>
Date: Tue, 24 Feb 2004 12:32:00 -0500

Peter: See at the bottom.

On Mon, Feb 23, 2004 04:12:48AM -0500, Busschbach, Peter B (Peter)
allegedly wrote:
> 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.

On Mon, Feb 23, 2004 04:26:19AM -0500, Busschbach, Peter B (Peter)
allegedly wrote:
> 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.

I was thinking of a different part of the problem.  In the case you
describe, where some entity has the intention of setting up a path de
novo, your approach feels good, including the use of RSVP(+) for the
critical points on the path to discover what resources are available and
agree on what needs to be allocated.  However, there are variables,
including pre-existence of PSN tunnels and PWs (of various sorts, not
just LSPs), whether the originator intends stitching to be involved in
PW setup, how discovery is done, and so forth.  

Let's decompose the problem space a little more.

Have a good time in Seoul ... Scott