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

From: [email-masked]
Date: Tue, 2 Aug 2005 21:23:43 +0100

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
> 

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Aug 2005 04:15:42 -0400

Neil,
         Yes, re-invention is inevitable, but 
we're not talking NSIS here.  My understanding of 
the proposal on the table is that there is a 
desire to extend LDP to meet PW specific 
requirements.  The changes include QoS, 
identification intermediate hops, recording of 
path used, bi-directional LSP, (possibly) 
end-point identification, etc.  All of these have 
been done before *for LDP*.  Also they have been 
done in a generic, non-application specific context.

My point is simply that since there are already 
TLVs defined for LDP that can be used to meet the 
PW requirements, we should not define new TLVs 
but rather use the ones that already exist.

Lou

At 04:23 PM 8/2/2005, [email-masked] wrote:

>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
>
> [<mailto:[email-masked]>mailto:[email-masked]] 
> On Behalf Of Lou Berger
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > > > From: [email-masked] 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > On Behalf
> > > > > Of Luca Martini
> > > > >
> <https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce 
>
> > > >
> > >
> > ><https://www1.ietf.org/mailman/listinfo/pce>h 
> ttps://www1.ietf.org/mailman/listinfo/pce
> >
> >
> <https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce 
>
> >