Subject: Re: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft? (fwd)

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 13 Jun 2005 11:24:39 -0700 (PDT)

Hi Luca,

On Tue, 7 Jun 2005, Luca Martini wrote:

> Rahul,
>
> This draft really has no relation to the automatic placing of PW along a
> path. It does not offer any solution in that respect other then manual
> provisioning.

Such automatic placing of PWs along a path is *one* of the requirements of
MS-PWs. Its not the only requirement. The solution in this draft can be
used to meet a *subset* of the requirements of MS-PWs and in that regard
it is one of the candidate MS-PW solutions and should be treated the same
way as the WG is treating the other MS-PW solutions.

> This is the basis for Interworking the control plane of many PWs , such
> as L2TPv3 , LDP( FEC 128/129) , and static PWs.

Other than MS-PWs, is there another application for such inter-working ?

>
> Regardless of what protocol we choose to signal multi hop PWs , we must
> have a document that defines the control plane signaling Interworking
> between different PW setup protocols.
>

And what is the reason for defining such inter-working other than to setup
MS-PWs ?

rahul

> Luca
>
>
>
> Rahul Aggarwal wrote:
>
> >Hi Stewart,
> >
> >On Mon, 6 Jun 2005, Stewart Bryant wrote:
> >
> >
> >
> >>The authors of
> >>
> >>draft-martini-pwe3-pw-switching-03.txt
> >>
> >>have asked that the draft be adopted as a WG draft.
> >>
> >>What is the consensus of the PWE3 WG?
> >>
> >>
> >>
> >
> >The above draft is one of the candidate solutions in the MH-PW solution
> >space.
> >
> >To quote you and Danny from your email that described the way forward
> >after the discussion on draft-raggarwa-rsvpte-pw:
> >
> >"The issue then becomes one of how to move forward.
> >
> >There are a number of candidate signaling protocols, and
> >we propose that we set a limit of three weeks before the
> >next IETF (i.e. -00 cutoff) for any further candidate
> >proposals to address the MS-PW signaling requirements.
> >
> >Evaluating the candidate signaling protocols and testing the
> >consensus of the WG on the best way to proceed will be
> >the major work item at the next IETF.
> >
> >Stewart/Danny"
> >
> >The above implies that *no* candidate signaling solution will be
> >adopted by the WG in the domain of MH-PWs till all the candidate
> >signaling protocols are discussed in the next IETF.
> >
> >So let us first discuss all the MH-PW signaling solutions
> >and the applicability of each before deciding which one to adopt and for
> >which set of requirements. Until then this draft or other drafts in the
> >MH-PW solution space, should not be adopted as WG documents.
> >
> >Thanks,
> >rahul
> >
> >
> >
> >>- Stewart
> >>
> >>
> >>
> >>_______________________________________________
> >>pwe3 mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>
> >>
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Tue, 14 Jun 2005 18:05:51 -0600

Rahul,

This is not an  MS-PW solution other then Interworking of the control 
planes. we are getting lost in terminology.
The automatic path selection that you can achieve by different schemes , 
RSVP, routing protocol etc. etc. *is * what will be discussed at the 
next meeting.
Whether we abandon all current protocols to setup PWs *is not* for 
discussion. ( or at least i do not think i heard anything along these 
lines ...)

Are you suggesting that we completely abandon all pwe3 work to date , 
and L2TPEXT WG work ?

If not , then we need a document that explains how different PW control 
protocols are talking to each other.

I see no reason why we need to stop this work to wait for the discussion 
at the next IETF. Besides , if the WG should decide to go a different 
route at a future time , we can change this draft , or drop it completely.

Can this document be used to build MS-PW solution ? I would think yes.
However this is not the part of the solution that we have discussed on 
this list or in the last IETF PWE3 meeting.

This document does not restrict any of the MS-PW automatic path 
selection solution space. If we go with RSVP , we will need a method to 
interwork RSVP with LDP , and with L2TPV3. This is what this document 
describes.

>Other than MS-PWs, is there another application for such inter-working ?
The application is to enable PWs to connect among heterogeneous PSNs , 
IP and MPLS.

>And what is the reason for defining such inter-working other than to setup
The reason is to have the ability to connect PWs running on different 
PSNs, and using different PW setup and maintenance protocols, such as 
LDP fec 128 , static , LDP FEC 129, and possibly even RSVP.

Luca

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 23 Jun 2005 10:52:01 -0700 (PDT)

Hi Luca,

>Are you suggesting that we completely abandon all pwe3 work to date ,

No.

> protocols are talking to each other.

And the only reason for wanting such interworking is to setup MS-PWs. This
is the point that is being made.

> route at a future time , we can change this draft , or drop it completely.

Different "route" for solving which problem ?

> Can this document be used to build MS-PW solution ? I would think yes.

We are in agreement on something :)

> LDP fec 128 , static , LDP FEC 129, and possibly even RSVP.

And why would one want to "connect" these PWs ? When you connect two
single segment PWs, what do you get ? Some would say a multi-segment
PW.

Let me clarify, that I am not arguing against
draft-martini-pwe3-pw-stitching. All I am saying is that it should be
treated by the WG just like other MS-PW solutions are being treated and
shouldn't be made into a WG document at this point.

rahul