Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt

From: <[email-masked]>
Date: Fri, 13 Apr 2007 16:19:00 +0100

> Folks,
> As discussed in the meeting, I'd like to solicit WG feedback on
> adopting this as a WG document.   If you're in favor or opposed
> to adopting this please speak up now.
> 
> -danny

I support draft-bryant-pwe3-mpls-transport becoming a WG document as it
provides a mechanism for transporting one party's MPLS network over
another's (which we have a requirement for) using existing deployed
technology.

Ben

-- 
Ben Niven-Jenkins
Network Architect, BT
  
E-mail: [email-masked] 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

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

---

From: <[email-masked]>
Date: Fri, 13 Apr 2007 17:19:26 +0100

Agreed Ben....operators need a method to carry the MPLS layer network of
one party over the MPLS layer network of another party in a transparent
client/server manner, ie the client and server layer MPLS networks are
functionally decoupled.  Stewart's draft is showing one way to achieve
this using existing mechanisms based on PWs.  So, from this 'requirement
perspective' I also support the draft becoming a WG document....though I
should add that I can think of other ways to achieve this and so we
should also be open to consider alternatives in the future. 

regards, Neil
BT Global Services CTO 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 13 April 2007 16:19
> To: [email-masked]
> Subject: [PWE3] Fwd: I-D 
> ACTION:draft-bryant-pwe3-mpls-transport-00.txt
> 
> 
> 	
> > Folks,
> I support draft-bryant-pwe3-mpls-transport becoming a WG 
> document as it provides a mechanism for transporting one 
> party's MPLS network over another's (which we have a 
> requirement for) using existing deployed technology.
> 
> Ben
> 
> -- 
> Ben Niven-Jenkins
> Network Architect, BT
>

---

From: "O'Connor, Don" <[email-masked]>
Date: Mon, 16 Apr 2007 17:57:36 -0500

Neil and Ben

This can be accomplished by the Generic PW concept that has been previously discussed in PWE3. For reference please see the following email thread

http://www1.ietf.org/mail-archive/web/pwe3/current/mail38.html

An email from Danny on 1/30/06 indicated (with respect to Generic PW)

"One application for the service would be a SP transit domain
in which it was desired that there was no interaction between
the client and transport network protocols (e.g., MPLS LSP
transport services w/no LDP interaction between the transport
and client networks)."

Is this the capability that you are seeking ?

In order to address the Generic PW application, it is not necessary to make draft-bryant a WG draft 

Do you have an opinion / view on Generic PW?

Regards

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 13, 2007 11:19 AM
To: [email-masked]
Subject: RE: [PWE3] Fwd: I-D

regards, Neil
BT Global Services CTO

---

From: <[email-masked]>
Date: Tue, 17 Apr 2007 08:01:55 +0100

Don...please see in-line.....

> From: O'Connor, Don [mailto:[email-masked]] 
> Sent: 16 April 2007 23:58
> To: Harrison,N,Neil,JCGA1 R; [email-masked]
> This can be accomplished by the Generic PW concept that has 
> been previously discussed in PWE3. For reference please see 
> the following email thread
> 

NH=> Essentially yes.  I don't know how far the records go back, but I
can recall suggesting to Danny and Stewart the need for an 'MPLS PW' way
before this.  At the time I don't think many other folks had foreseen
that there would be a need at some point for a MPLSoverMPLS C/S
(client/server) layer network relationship.  I should, however, add that
I don't like the manner in which this would have to be done....BUT,
given the way MPLS has been designed it is the best one can do.  We
cannot (repeat cannot) afford to go back now and redesign MPLS.  It's
too late.  There is too much MPLS as-is out there.  We have to now find
a C/S solution from what exists.  I'll come back on this point below.

> 
> In order to address the Generic PW application, it is not 
> necessary to make draft-bryant a WG draft 
> 
NH=> Yes.  For a start a generic PW is actually a contradiction in
terms.  PWs should never have existed.  MPLS itself should have been
'generic' and designed from the outset to support all clients in a
consistent manner if it was going to do more than be an IP-booster.  It
is the special treatment of IP (ie null encaps *OR* peer PDU...which
that is truly bizarre from a func arch layer network perspective if you
grok what I mean by this) and MPLS (ie nested LSPs get the wrapper
treatment, with the lovely illusion that one can create topology on the
fly by simply adding another MPLS labelled header) that creates most of
the downstream problems.

Note - It is the above observation that is the real architectural
problem.  The violation of the rules of a connection by allowing merging
(vanilla LDP and PHP) are secondary problems.  Ditto the lack of simple
and correctly specified OAM, no OBB control/management, etc....these are
all secondary symptoms.  Note also these problems do not afflict GMPLS
because one cannot misuse the co-cs mode due to way labelling and
resource partitioning work here.

PWs are therefore simply a consequential spawn of this anomalous design.
Whilst they remained 1-hop they could be considered as an adaptation
function (though most of the fields would be redundant in a properly
designed co-ps mode layer network)...however, once PWs go multi-hop they
become a new full-blown co-ps mode layer network in their own right.
And that, I am afraid, is a really bad consequence.

I was making these observations maybe 5 or more years ago on the PWE3
list and they were ignored.  It is now far too late.  We cannot now
afford to go back and re-engineer MPLS.

One thing folks need to be quite clear on is that we do not need to
address all the resource partitioning, etc issues in MPLS to obtain a
C/S relationship...we can get this without a major re-engineering of
MPLS.

MPLS is based on the ability to arbitrarily stack/nest LSPs.  This means
that such stacked/nested LSPs all belong to the same MPLS layer
network....in functional architecture terms stacked/nested LSPs are
sublayer constructs within the same MPLS layer network.  What this means
practically is that it is not possible to directly carry an LSP
belonging to the MPLS network of party A say over an LSP belonging to
the MPLS network of party B say in a truly transparent functionally
decoupled manner.  In other words stacked/nested LSPs do not
intrinsically provide a client/server layer network relationship.  

One solution to the problem is to use existing PW techniques to insert a
different technology between the two MPLS networks (of say party A and
party B as noted above).  This provides a 'functional breakwater'
between the 2 MPLS networks.  This could, in principle, use any PW
technology.  However, in Stewart's document a choice has been made to
use an Ethernet PW as defined in rfc4448.  

I can think of a possibly more simple/elegant solution (that also has
other benefits) by using a reserved label to act as a functional 'stack
delimiting label', and thus avoid the need to insert another technology
to provide the functional breakwater between the MPLS networks
owned/operated by different parties.

However, the key purpose of Stewarts document is to show that there is a
solution to providing a C/S behaviour using already defined IETF
standards without having to undertake a major re-engineering of
MPLS....and as I have already noted, it is far too late to countenance
this anyway IMO.

regards, Neil

> Agreed Ben....operators need a method to carry the MPLS layer 
> network of one party over the MPLS layer network of another 
> party in a transparent client/server manner, ie the client 
> and server layer MPLS networks are functionally decoupled.  
> Stewart's draft is showing one way to achieve this using 
> existing mechanisms based on PWs.  So, from this 'requirement 
> perspective' I also support the draft becoming a WG 
> document....though I should add that I can think of other 
> ways to achieve this and so we should also be open to 
> consider alternatives in the future. 
> 
> regards, Neil
> BT Global Services CTO 
>