Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE.

From: "Cupit, John" <[email-masked]>
Date: Tue, 2 Aug 2005 15:54:44 -0500

Neil:

For what is it worth, you comments bespeak experience as well as common sense.  From my perspective, MPLS has been and will continue to be a transport technology - a means of providing connection orientation for a connectionless protocol (IP).  As such, our focus should be on the selection of uniform signaling mechanisms for co-cs and co-ps networks that effectively allow our customers to provision a light path (in a metro DWDM network, for example) which contains a corresponding MPLS tunnel and a PWE3 virtual circuit within that tunnel, supporting a legacy attachment circuit such as a Frame Relay service.  It is our belief that all of our customers are looking for a uniform control plane which would support psuedowire termination as well as psuedowire switching on both IP and sub-IP networks.  As such, simple uniformity becomes the key objective.

Much has been written and much has been spent in support of "convergence".  If we are truly serious in supporting the reach of PWE3 technologies to the carrier industry - we need to be more serious in establishing a uniform signaling approach which can be deployed in the access, IOF, Service Edge and Core portions of the network.  Otherwise, I feel that we are doing nothing more than positioning additional overlays for the network operator to muck about with.

I join in your call for a common solution.

Regards,

JC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tuesday, August 02, 2005 3:24 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE.

Lou/folks,

Why not re-invent the wheel?...after all PNNI was there long ago on many topics folks here aspire to.  And wrt the routing aspects this was pretty good at handling hierarchy as I recall, and didn't signalling here have crankback?  But seriously folks, isn't this (wheel re-invention) THE issue here, ie against the 3 network modes (cl-ps, co-ps and co-cs) there are only so many ways to 'do' functional components, so wheel re-invention is unavoidable by definition....here the topic is signalling, but it could be addressing, routing, OAM, whatever.

Now despite the hype all engineers I know who are worth their salt know it is simply not technically sensible, let alone commercially viable, to try and functionally crunch all layer networks from IP to Optics (ie acrosss the 3 modes) then why not and have some honesty/truth for a change?......prescriptive doctrines can only work for a while on the masses and truth has a nasty habit of coming to the surface eventually....be it via law-suits, eg Ebbers, or practical deployment experience.

For the record:  IF the selection of a signalling functional component is down to RSVP-TE vs LDP (which means CR_LDP in practice for any sensible co mode technology) then I vote for a COMMON solution between the control of co-cs mode technologies (ie GMPLS) and co-ps technologies (ie MPLS), ie RSVP-TE.    Note - there is not a 'common' in the sense of single instance of functional component which operates across all layer networks, as it operates in a disjoint networking space in each layer network, but it is 'common' in the sense that it is the SAME choice of functional component in each disjoint networking space.  Now the co-cs mode FORCES certain behaviours here in GMPLS (like OOB, no QoS classes, true client/server hierarchy, no LDP-like mp2p merging, no trails stopping short of their trail term pt (ie PHP in MPLS)) and these are VERY GOOD THINGS.....so let's please carry these over to the co-ps mode in MPLS.  CCAMPs folks have chosen RSVP-TE for this environment.....not saying it's THE best functional choice for signalling, but it is the one that has been made and it seems to work fine.  Now discussions on PWE3 are in the context of MH-PWs, but if we are honest here architecturally this means 'XoverIP' != 'XoverMPLS' != XoverGMPLS'  since GMPLS (co-cs mode), MPLS (co-ps mode) and IP (cl-ps mode) are all required to operate in concert.  So IMO PWE3 folks have done a great diservice to progress by erroneously assuming MPLS==IP....and clearly this can't be true else MPLS (nor GMPLS) would exist as a *data-plane* technologies period.  So IMO we should accept/recognise the differences in the 3 modes and stop pretending they are 'all the same'.....it's these differences that we should seek to exploit.  And I'm all for functional component re-use......but PLEASE don't try and kid us this is one flat network, it clearly isn't.

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 02 August 2005 18:42
> To: LE ROUX Jean-Louis RD-CORE-LAN
> Cc: pwe3; Luca Martini; [email-masked]
> Subject: RE: [Pce] RE: [PWE3] Correction of my statement 
> regarding PCE.
> 
> 
> JL,
>          See below.
> 
> At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> >Hi Luca,
> >
> > >We will need PCE to produce the computed path ,
> > > which could then be signaled by either RSVP or LDP.
> >
> >I'm really curious to know how LDP will be used
> >to signal an explicit path computed by the PCE...
> >CR-LDP???
> 
> sure, why not?  If we *must* use an LDP based 
> solution, it's better to start with CR-LDP (or a 
> CR-LDP subset) than reinventing the wheel!
> 
> Lou
> 
> PS (yes, I have my bullet proof vest on!)
> 
> >Regards,
> >
> >JL
> >
> > > -----Message d'origine-----
> > > De : [email-masked] 
> [mailto:[email-masked]] 
> > > De la part de Don Fedyk Envoyé : mardi 2 août 2005 15:19
> > > À : Luca Martini; pwe3; [email-masked]
> > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE.
> > >
> > > Luca:
> > >
> > > Is the PWE Multi-Stitching topology congruent with the 
> GMPLS IGP/EGP 
> > > topology?  It was my understanding there is no constraint 
> assuming 
> > > this. Therefore I think you have an additional 
> requirement that PCE
> > > model support multiple Topologies.
> > >
> > > Just curious,
> > > Don
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf
> > > > Of Luca Martini
> > > >
> > > > Now, If Lou Had not derailed my thoughts ...
> > > >
> > > > What I meant to say was that neither RSVP-TE  nor any
> > > flavors of LDP
> > > > can properly solve the problem of computing the shortest
> > > path between
> > > > two domains/AS/areas. We will need PCE to produce the
> > > computed path ,
> > > > which could then be signaled by either RSVP or LDP.
> > > >
> > > > I believe that we often do not make the distinction between
> > > the C-SPF
> > > > calculation and RSVP-TE.
> > > >
> > > >
> > > > Luca
> > >
> > >
> > > _______________________________________________
> > > Pce mailing list
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/pce
> > >
> >
> >_______________________________________________
> >Pce mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pce
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

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

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

---

From: "T.Shimizu" <[email-masked]>
Date: Wed, 3 Aug 2005 16:13:38 +0900

Hi, All.

I partially agree with C.John.

My comment are;

Policy should not be included in PCE Arch ID, because it has many factors
and
discussion can not reach conclusion.

For PCE Arch ID, Single Pattern  and Fully Abstracted Model is
preffered for eliminating complexity.
The Model at least includes;

   - Path/Circuit Model
     VP/VC based Model may be better.
     VP is LSP with single Label stack.
     Multi-Label Stack LSP is not adopted since it is cmplicated.
     VC is Sub-LSP according to FEC in the above LSP.
     Alternative VP is considered up to 3 LSP.

   - QoS Model
     8 Level Priority based Model as COS/TOS may be better.
     This Priority Class is mapped with VC.

   - Metric Model include
     Static Bandwidth of LSP
     Dynamic(Available) Bandwidth of LSP/Sub-LSP

   - Operation Model
     LSP Initial computing
     LSP Dynamic best selection amog the LSPs
     LSP Protection Notiification in case of fault

   As for PWE3 or other System, it may be better to discuss later on.

Best Regards

--------
T. Shimizu

----- Original Message ----- 
From: "Cupit, John" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 03, 2005 5:54 AM
Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE.

Neil:

For what is it worth, you comments bespeak experience as well as common
sense.  From my perspective, MPLS has been and will continue to be a
transport technology - a means of providing connection orientation for a
connectionless protocol (IP).  As such, our focus should be on the selection
of uniform signaling mechanisms for co-cs and co-ps networks that
effectively allow our customers to provision a light path (in a metro DWDM
network, for example) which contains a corresponding MPLS tunnel and a PWE3
virtual circuit within that tunnel, supporting a legacy attachment circuit
such as a Frame Relay service.  It is our belief that all of our customers
are looking for a uniform control plane which would support psuedowire
termination as well as psuedowire switching on both IP and sub-IP networks.
As such, simple uniformity becomes the key objective.

Much has been written and much has been spent in support of "convergence".
If we are truly serious in supporting the reach of PWE3 technologies to the
carrier industry - we need to be more serious in establishing a uniform
signaling approach which can be deployed in the access, IOF, Service Edge
and Core portions of the network.  Otherwise, I feel that we are doing
nothing more than positioning additional overlays for the network operator
to muck about with.

Regards,

JC

-----Original Message-----

Lou/folks,

Why not re-invent the wheel?...after all PNNI was there long ago on many
topics folks here aspire to.  And wrt the routing aspects this was pretty
good at handling hierarchy as I recall, and didn't signalling here have
crankback?  But seriously folks, isn't this (wheel re-invention) THE issue
here, ie against the 3 network modes (cl-ps, co-ps and co-cs) there are only
so many ways to 'do' functional components, so wheel re-invention is
unavoidable by definition....here the topic is signalling, but it could be
addressing, routing, OAM, whatever.

Now despite the hype all engineers I know who are worth their salt know it
is simply not technically sensible, let alone commercially viable, to try
and functionally crunch all layer networks from IP to Optics (ie acrosss the
3 modes) then why not and have some honesty/truth for a
change?......prescriptive doctrines can only work for a while on the masses
and truth has a nasty habit of coming to the surface eventually....be it via
law-suits, eg Ebbers, or practical deployment experience.

For the record:  IF the selection of a signalling functional component is
down to RSVP-TE vs LDP (which means CR_LDP in practice for any sensible co
mode technology) then I vote for a COMMON solution between the control of
co-cs mode technologies (ie GMPLS) and co-ps technologies (ie MPLS), ie
RSVP-TE.    Note - there is not a 'common' in the sense of single instance
of functional component which operates across all layer networks, as it
operates in a disjoint networking space in each layer network, but it is
'common' in the sense that it is the SAME choice of functional component in
each disjoint networking space.  Now the co-cs mode FORCES certain
behaviours here in GMPLS (like OOB, no QoS classes, true client/server
hierarchy, no LDP-like mp2p merging, no trails stopping short of their trail
term pt (ie PHP in MPLS)) and these are VERY GOOD THINGS.....so let's please
carry these over to the co-ps mode in MPLS.  CCAMPs folks have chosen
RSVP-TE for this environment.....not saying it's THE best functional choice
for signalling, but it is the one that has been made and it seems to work
fine.  Now discussions on PWE3 are in the context of MH-PWs, but if we are
honest here architecturally this means 'XoverIP' != 'XoverMPLS' !=
XoverGMPLS'  since GMPLS (co-cs mode), MPLS (co-ps mode) and IP (cl-ps mode)
are all required to operate in concert.  So IMO PWE3 folks have done a great
diservice to progress by erroneously assuming MPLS==IP....and clearly this
can't be true else MPLS (nor GMPLS) would exist as a *data-plane*
technologies period.  So IMO we should accept/recognise the differences in
the 3 modes and stop pretending they are 'all the same'.....it's these
differences that we should seek to exploit.  And I'm all for functional
component re-use......but PLEASE don't try and kid us this is one flat
network, it clearly isn't.

regards, Neil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 3 Aug 2005 11:07:44 +0200

Hi,

> discussion can not reach conclusion.

Policy is undoubtedly a key component of the PCE architecture and as  
such must be included in the PCE architecture as agreed by the WG.  
Detailed policy requirements as well as potential protocol extensions  
will be part of separate IDs.

>      LSP Protection Notiification in case of fault

There is a mix of items above, some of which are clearly out of the  
scope of the WG.

Thanks.

JP.