Subject: RE: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft?

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 7 Jun 2005 15:02:06 +0200

Very strongly support.

Y(J)S 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: Tuesday, June 07, 2005 00:17
> To: pwe3
> Subject: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft?
> 
> 
> 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?
> 
> - Stewart

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

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 7 Jun 2005 15:55:08 -0400

Rahul,

	In addition to asking for a dead-line for candidate protocols,
we also should want to clearly understand what requirements (or subset
of requirements each candidate protocol proposal is likely to address.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Rahul Aggarwal
--> Sent: Tuesday, June 07, 2005 3:49 PM
--> To: Stewart Bryant
--> Cc: pwe3
--> Subject: Re: [PWE3] draft-martini-pwe3-pw-switching-03.txt 
--> as WG draft?
--> 
--> 
--> 
--> 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
-->

---

From: [email-masked]
Date: Wed, 8 Jun 2005 09:09:39 +0100

Luca...an observation...

If the 'signalling' chosen is not influencing the actual path selection
process then I would argue this is not *network* signalling at
all....this is more akin to session signalling whose only role is to
configure the end-points. Given this observation then it kind-of begs
the question 'so what has multi-hop got to do with this?'.....because by
definition multi-hop means one is selecting/touching more than 2
end-points.

This then raises many other issues related to nested layer layer
networks....like route-selection/oam/resilience/etc at each level.
However, given the creation of topology of layer N is dependent on
ALREADY provided link-connections in layer N via trails in layer N-1,
and so on to the duct, this is all looking a fairly broken idea to me
and folks here.  Stuff can work OKish provided (i) the wrapper behaviour
of MPLS is kept latent, ie real networking only exists at 1 level (which
is true for old PWs as these were simply 1-hop 'session entities') and
(ii) we stay within the bounds of a single operating party.  But if one
wants true multi-hop *networking* (and I emphasise the word networking)
at the PW level, or more generally in ALL cases where one has a
client/server relationship between the networks (ANY) of 2 disjoint
commercial operating parties, one really needs to consider the PW layer
and the underlying server layer network (whatever that is) as 2 distinct
layer network entities....but you can't, and that is the fundamental
problem in all this stuff, ie one cannot create functionally decoupled
layer networks....there is a view that somehow everything can be
regarded as a single layer network, but this is just plain wrong be it
from a technical or a commercial perspective.

I just wonder how much longer this deeper architecture/commercial
problem will be allowed to exist before it is recognised as such?  I
must admit however that I am quite amazed this has got as far as it has.

regards, Neil

> Behalf Of Luca Martini
> Sent: 08 June 2005 05:46
> To: Rahul Aggarwal
> Cc: pwe3; Stewart Bryant
> Subject: Re: [PWE3] draft-martini-pwe3-pw-switching-03.txt as 
> WG draft?
> 
> 
> 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.
> This is the basis for Interworking the control plane of many 
> PWs , such 
> as L2TPv3 , LDP( FEC 128/129) , and static PWs.
> If the WG where to adopt a PW signaling method based on some other 
> protocol ( say, maybe RSVP ;-) ) I would definitely add a section to 
> include such protocol  as one of the protocols used to setup a PW.
> 
> 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.
> 
> Luca
> 
> 
> 
> Rahul Aggarwal wrote:
> 
> >Hi Stewart,
> >
> >On Mon, 6 Jun 2005, Stewart Bryant wrote:
> >
> >  
> >
> >>The authors of
> >>
> >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
> >>
> >>
> >>

---

From: [email-masked]
Date: Wed, 8 Jun 2005 14:28:43 +0100

I support draft-martini-pwe3-pw-switching-03.txt becomming a working group
document.

However, I do not support draft-balus-mh-pw-control-protocol-01.txt, or any
other fully dynamic solution becoming a WG document yet. This would be
premature as the current draft only addresses a small a part of the MS-PW
signalling problem. In any case, the MS-PW requirements draft is only just
reaching this stage. Applicability statements for each dynamic solution
would be very helpful in understanding which, if any, meet the
requirements.

 Cheers,

Matthew

|---------+--------------------------->
|         |           David McDysan   |
|         |           <dave.mcdysan@mc|
|         |           i.com>          |
|         |           Sent by:        |
|         |           pwe3-bounces@iet|
|         |           f.org           |
|         |                           |
|         |                           |
|         |           08/06/2005 14:00|
|         |                           |
|---------+--------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                |
  |        To:      "'Andrew G. Malis'" <[email-masked]>, "'Florin Balus'" <[email-masked]>                               |
  |        cc:      "'pwe3'" <[email-masked]>, "'Stewart Bryant'" <[email-masked]>                                              |
  |        Subject: RE: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft?                                                 |
  >--------------------------------------------------------------------------------------------------------------------------------|

I support this recommendation as well.

Dave

> Behalf Of Andrew G. Malis
> Sent: Tuesday, June 07, 2005 10:49 PM
> To: Florin Balus
> Cc: pwe3; Stewart Bryant
> Subject: RE: [PWE3] draft-martini-pwe3-pw-switching-03.txt as
> WG draft?
>
> I agree with Florin that both
> draft-martini-pwe3-pw-switching-03.txt  and
> draft-balus-mh-pw-control-protocol-01.txt become WG drafts,
> for the reasons he stated.
>
> Thanks
> Andy
>
> ----------
>
> At 6/7/2005 11:29 -0400, Florin Balus wrote:
>
> >Stewart,
> >I think extending the existing LDP-based solution is the
> right way to
> >move ahead in the Multi-Hop/Segment PWs space. I support
> >draft-martini-pwe3-pw-switching-03.txt becoming WG draft as
> a baseline
> >for LDP-based solution.
> >
> >Could you send also a separate call for
> >draft-balus-mh-pw-control-protocol-01.txt to become a PWE3
> WG document.
> >We think it builds on top of  draft-martini-pwe3-pw-switching-03.txt,
> >specifying extensions to LDP for dynamic, hop-by-hop signaling of
> >Multi-Hop/Segment PWs.
> >
> >Regards,
> >Florin
> >
> > >From: [email-masked] [mailto:[email-masked]]
> On Behalf
> > >Of Stewart Bryant
> > >Sent: Monday, June 06, 2005 6:17 PM
> > >To: pwe3

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 8 Jun 2005 09:36:18 -0400

Same here.

I think Martini draft lays a good foundation for MS-PW
and should become WG draft.

However, dynamic signalling of MS-PW is THE topic of discussion
for upcoming IETF meeting, lets not preempt that effort.

/himanshu

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, June 08, 2005 9:29 AM
> To: David McDysan
> Cc: [email-masked]; 'pwe3'; 'Stewart Bryant'
> However, I do not support 
> draft-balus-mh-pw-control-protocol-01.txt, or any
> >-------------------------------------------------------------
> -------------------------------------------------------------------|
>   |                                                           
>                                                                      |
>   |        To:      "'Andrew G. Malis'" 
> <[email-masked]>, "'Florin Balus'" <[email-masked]>  
>                              |
>   |        cc:      "'pwe3'" <[email-masked]>, "'Stewart 
> Bryant'" <[email-masked]>                                 
>              |
>   |        Subject: RE: [PWE3] 
> draft-martini-pwe3-pw-switching-03.txt as WG draft?           
>                                       |
>   
> >-------------------------------------------------------------
> -------------------------------------------------------------------|
> 
> 
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 8 Jun 2005 17:14:02 +0200

Neil, 

I read your email several times, 
and must confess that I can't follow your arguments
regarding MS PWs.

For the multisegment case, we terminate the MPLS layer
of one network (we have to since we are going into another
administrative domain or onto another PW technology)
and are left with the PW layer.

The PW layer is treated just as an MPLS layer would be,
with the label being swapped in order to belong to the 
label space of the new domain.

The two domains are in a peering relationship
and represent a G.805 partitioning of the PW layer network.
In order to ensure the integrity of the trail
at the PW layer, we have VCCV running as OAM.

In the new domain the PW is now placed onto
a new server layer, which may happen to be MPLS
(or may be something else such as carrier Ethernet or L2TPv3).

The MS PW signaling operates at the PW layer.
At the PW layer we usually only signal between endpoints,
relying on the underlying tunnel making placement trivial.
But here we have two separate tunnels that need to be joined,
so we need signaling that ensures that we reach
the stitching point, and that both directions go through
the same stitching point.

So where do you see any architectural problem?
We are not (here at least) suggesting any confusion between
CO and CL server layers.
We are not performing any (new) G.805 layer violations.
All we are doing is recognizing that the PW layer
is a true layer network, one that in the MPLS case
is simply a continuation of the G.8110 recursion.

Y(J)S

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 15 Jun 2005 13:12:10 -0700

Folks,

Quoting some of the recent e-mails on the topic:

>From Florin Balus: 

   I think extending the existing LDP-based solution is the right
   way to move ahead in the Multi-Hop/Segment PWs space. I support
   draft-martini-pwe3-pw-switching-03.txt becoming WG draft as a
   baseline for LDP-based solution.

>From Himanshu Shah:

   I think Martini draft lays a good foundation for MS-PW ...

>From Eric Gray:

   This draft addresses the need for multi-hop pseudo-wires ...

>From Luca Martini:

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

With this in mind I'd like to remind you of an expression that
if it walks like a duck, and if it squeakes like a duck, it is
a duck.

Let's be honest with ourselves - this document *does* provide *a
way* to construct multi-hop/segments pseudo-wires. Therefore, this
document should be handled the same way as the other proposals for
multi-hop/segments pseudo-wires, and should *not* be accepted  as
a WG document *at the present moment*.

Yakov.