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
> 

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

---

From: Luca Martini <[email-masked]>
Date: Wed, 03 Aug 2005 01:34:20 -0600

LE ROUX Jean-Louis RD-CORE-LAN wrote:
> I'm really curious to know how LDP will be used to signal an explicit path computed by the PCE...
> CR-LDP???
> 
Not quite. Some kind of explicit PW route object containing some 
addressing ( probably not IP ) does not turn LDP into CR-LDP.
We are also still using DU mode not DOD.

Luca

>> [mailto:[email-masked]] De la part de Don Fedyk
>> Envoyé : mardi 2 août 2005 15:19
>> 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

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 3 Aug 2005 08:40:57 -0400

I will add that even before starting to analyze if we need a view of
MS-PW Network Elements (i.e. U-PE-Virtual Link (MPLS
Tunnel)-S-PE-Vlink-S-PE-etc) those MPLS tunnels linking the x-PEs should
be RSVP-TE signaled. Or what we saw in most of the networks are LDP
based tunnels between most of the PEs. 

So I would say that at the minimum we do need to provide LDP-based
Signaling Procedures for MS-PWs.

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Thomas D. Nadeau
>Sent: Wednesday, August 03, 2005 5:04 AM
>To: pwe3 ((E-mail))
>Cc: Mark Townsley
>Subject: Re: [PWE3] Correction of my statement regarding PCE.
>
>
>
>     Before we go down the road of building PCE into
>the MH-PW solution, let me pose what seems to me
>an obvious question. Are paths that are optimal
>end-to-end (or explicitly routed) always required for
>MH-PWs or or it necessary for some subset of cases?
>I want to make sure we don't over-engineer anything here.
>If some people are willing to go with a simple solution
>where paths that are sub-optimal end-to-end (albeit
>optimal locally) might be okay.  I suspect this
>might even be a large set of cases.
>
>     --tom
>
>
>
>> Hi,
>>
>> Let me build on what Luca says by typing from the front of 
>the PCE WG 
>> meeting (where I should be concentrating on what JP is saying, but
>> there
>> are limits even to my concentration abilities). Luca is right that
>> signaling paths is not computing paths.
>>
>> We also need to distinguish between the different PCE models.
>>
>> There are hundreds of instances of PCE already deployed in networks
>> today.
>> Those PCEs reside with (are part of) LSRs and/or NMSs. That is, a  
>> PCE is a
>> computation element that supplies a computation result on behalf of a
>> client that may be closely tied to the computation element.
>>
>> What the PCE working group is doing is examining other models where
>> the
>> PCE may be remote from the requesting client. In these models there  
>> may be
>> "one oracle in the sky" that can see all topology. There may be many
>> demi-gods that cooperate or operate independently. The demi-gods  
>> may have
>> limited visibility (i.e. within a domain).
>>
>> You can cut the cake many ways.
>>
>> Please read the PCE architecture (see the charter page).
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "Luca Martini" <[email-masked]>
>> To: "pwe3" <[email-masked]>
>> Sent: Tuesday, August 02, 2005 1:38 PM
>> Subject: [PWE3] Correction of my statement regarding PCE.
>>
>>
>>
>>
>>> 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.
>>>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 3 Aug 2005 12:39:44 -0400

Some comments in line....

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2005 7:41 PM
To: Shah, Himanshu; pwe3
Subject: Re: [PWE3] Correction of my statement regarding PCE.

Hi,

I am resisting the obvious "read the architecture I-D" answer, but
please
do read the architecture I-D.

himanshu> OK.

> I am confused on use of PCE in this context.
>
> Can PCE,
> 1) know about all the QOS info of soft/dynamic links (PWs do go over
> tunnels which in turn are soft, i.e. they can be created dynamically
for
> whatever b/w the underlying PSN can offer) of all the S-PEs between
> U-PEs? And handle the rate at which tunnels are created/removed,
up/down
> sized?

If the information is knowable, PCE can know it.

Himanshu> I think that is the point. Information is not knowable.
OSPF/CSPF Himanshu> work on available b/w on physical links. For MS-PW
case, PCE would Himanshu> have to take into consideration on available
b/w on the whole PSN Himanshu> between two PEs. Because, tunnels
(transport TE-LSPs) can be Himanshu> established dynamically. A PE could
do CAC for a MS-PW at the time Himanshu> MS-PW signal is received, by
actually triggering a new transport Himanshu> LSP and admit/fail based
on its ability to successfully create a Himanshu> new LSP or upsizing
the existing LSP.

/himanshu

How it is collected and passed to PCE might be an interesting
discussion.
MPLS-TE is reasonably good at handling "dynamic links" or "tunnels" that
are established with whatever b/w is requested and between many end
points.

Can PCE handle the rate at which tunnels are created/removed/modified?
This is largely an implementation and network architecture question. We
believe that it is possible to build PCE systems that can do this, and
that the protocol and structure will not impede this.

But it is possible that we do not understand the scale of the issue and
it
would be appropriate to bring some numbers and associated requirements
to
the PCE mailing list.

> 2) handle perhaps millions of PWs - after all PWs are multiplexed over
> LSPs, so it is definitely magnitude higher than LSPs that are
> anticipated for PCEs to scale with.

Not sure that the total number of PWs is relevant. The rate of arrival
of
computation requests might be more relevant as above.

But let us be clear: if paths need to be computed, then they must be
computed by someone. PCE is simply the thing that computes the path, it
is
not magic. The PCE architecutre will show you that it is a deployment
issue to decide where those computation elements are positioned. OTOH,
if
paths do not need to be computed, then why would you worry about PCE?

Thanks,
Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adrian Farrel
Sent: Tuesday, August 02, 2005 9:18 AM
To: pwe3
Subject: Re: [PWE3] Correction of my statement regarding PCE.

Hi,

Let me build on what Luca says by typing from the front of the PCE WG
meeting (where I should be concentrating on what JP is saying, but there
are limits even to my concentration abilities). Luca is right that
signaling paths is not computing paths.

There are hundreds of instances of PCE already deployed in networks
today.
Those PCEs reside with (are part of) LSRs and/or NMSs. That is, a PCE is
a
computation element that supplies a computation result on behalf of a
client that may be closely tied to the computation element.

What the PCE working group is doing is examining other models where the
PCE may be remote from the requesting client. In these models there may
be
"one oracle in the sky" that can see all topology. There may be many
demi-gods that cooperate or operate independently. The demi-gods may
have
limited visibility (i.e. within a domain).

Thanks,
Adrian

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "pwe3" <[email-masked]>
Sent: Tuesday, August 02, 2005 1:38 PM
Subject: [PWE3] Correction of my statement regarding PCE.

> 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
which
> I believe that we often do not make the distinction between the C-SPF
> calculation and RSVP-TE.
>
>
> Luca
>
>

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 4 Aug 2005 11:07:35 +0200

Hi Luca

Please see inline, 

> De : Luca Martini [mailto:[email-masked]] 
> Envoyé : mercredi 3 août 2005 09:34
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : Don Fedyk; pwe3; [email-masked]
> Objet : Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE.
> 
> 
> 
> >> We will need PCE to produce the computed path , which 
> could then be 
> Not quite. Some kind of explicit PW route object containing 
> some addressing ( probably not IP ) does not turn LDP into CR-LDP.

Why not taking leverage of the RSVP-TE explicit routing machinery, including inter-domain procedures, instead of introducing significant changes to LDP?
Frankly speaking I don't really see why we should choose between LDP and RSVP-TE for MH PW sig, why not progressing both approaches?
When explicit routing is not required then use LDP, and if explicit routing is required use RSVP-TE. This is what we are doing today for LSP signaling by the way...

Best Regards,

JL

> >> [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:
> >>
> >> 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
> >>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 4 Aug 2005 05:48:54 -0400

Luca,

> We are also still using DU mode not DOD.

PW route object? Are you referring to a route object that
contains a list of attachment identifiers that a multi segment 
pw traverses? Can you be more explicit on this route object?

Hamid.

---

From: [email-masked]
Date: Thu, 4 Aug 2005 11:17:38 +0100

Hi Luca

you wrote 04 August 2005 10:38

> Neil,
> 
> Don't you think that having an appropriate addressing scheme for the 
> multi segment PW is necessary ?
NH=> Interesting point you raise here.  Every layer network needs an addressing schema.  Indeed, even if you use v4 addressing in GMPLS for the *traffic* data-plane VC4 layer network in SDH this is not the same addressing space as the IP layer network v4 address space.  And of course the VC12 layer network also has its own address space, which could also be v4.  And neither of these are the *same* as the data-plane networks which carry their control/management-plane protocols.  So addressing (like routing) is not a single function spanning all layers.  And I wish this was better understood because I think too many folks still believe there is a 'common control-plane' running from IP to Optics.....there can't be, it makes neither technical nor commercial sense

MPLS is an odd-ball here as a layer network, but I don't really want to get into the nuances of the wrapper here (though its a fairly serious problem IMO and also lies at the heart of many other problems).

However, let me point this out.  We should never have created this PW layer network in the 1st place.  cl-ps(eg IP)!= co-ps(eg MPLS) != co-cs (eg GMPLS) and that is just a fact.  I know the history of arch violations/errors why we have arrived here and quite frankly its a mess....just looking at the stuff regarding the VCCV breakout group tells you something is very seriously wrong here.  However, having created this unnecessary layer network then yes addressing will have to be defined for it...and every other functional component that a layer network requires will also have to be added.
> 
> If so, it would mean major changes to RSVP-TE which only 
> supports ipv4 
> and ipv6 addressing right now.
NH=> What do you want me to say?.....perhaps something like, 'well done for yet another major error'?  I remember when I saw these 'addresses' being originally cooked-up saying to myself.....this is going to create a serious problem downstream.  Addressing is one thing you should pay great attention to at t=0....if you screw it up you are stuck with it for a very long time.  But hey, this stuff is built on a whole pile of compounded mistakes so why just pick on this one?  If you really want to fix thing you are going to have to go back quite a long way.  It may simply not be worth it now and perhaps folks should think of other ways to address (no pun intended) this client/server service issue.

regards, Neil
> 
> Luca
> 
> 
> [email-masked] wrote:
> > JL wrote 04 August 2005 10:08
> > 
> >> Hi Luca
> >>
> >> Please see inline,
> >>
> >>> addressing ( probably not IP ) does not turn LDP into 
> CR-LDP. We are 
> >>> also still using DU mode not DOD.
> >> Why not taking leverage of the RSVP-TE explicit routing machinery, 
> >> including inter-domain procedures, instead of introducing 
> significant 
> >> changes to LDP? Frankly speaking I don't really see why we should 
> >> choose between LDP and RSVP-TE for MH PW sig, why not progressing 
> >> both approaches? When explicit routing is not required 
> then use LDP, 
> >> and if explicit routing is required use RSVP-TE. This is 
> what we are
> >> doing today for LSP signaling by the way...
> >>
> >> Best Regards,
> >>
> >> JL
> > NH=> I largely agree. A signalling protocol is a signalling 
> > protocol....in other words you really only need one of them for 
> > providing this function.  Why an operator would wish to run 
> multiple 
> > types of the same functional component seems unclear.  A 1 
> hop trail 
> > is a degenerate case, ie its not a networked entity......but IMO it 
> > would seem rather silly just to have a different signalling 
> protocol 
> > for this special case, one may as well use the one that applies for 
> > the general case.  Minimising functional components should 
> also help 
> > minimise costs, at least as a general rule.  The other nice thing 
> > about using the GMPLS developed spin of RSVP-TE is that it 
> can be used 
> > OOB....and that has to be a good thing for 
> security/stability design 
> > considerations (though I am well aware MPLS has not been 
> designed like 
> > this, and that in GMPLS the co-cs mode forces good design practice 
> > anyway).
> > 
> > regards, Neil
> > 
>

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 4 Aug 2005 05:37:30 -0500

Agree Neil on this address mis-understanding - I have seen it multiple times. Many are confusing the use of NSAPs by the management plane as requiring the support in a control protocol. These NSAP addresses are very specific for the management plane application (user or service provider), and private. No different than a service provider using private addressing for their internal network, a user will require the same.

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 04, 2005 6:18 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE.

Hi Luca

regards, Neil

---

From: [email-masked]
Date: Thu, 4 Aug 2005 12:28:05 +0100

Yes I know Deborah.....but folks were spun some stories many years ago about 'common-control-planes' and far too many folks got the wrong understanding of what this means.  We've seen these problems coming for a very long time....and I've had my fair share of flames for trying to explain them......folks either don't understand what I have been saying or don't want to understand it, and its not always easy to work out which is which.

But this is more than the point you are picking out....when we are dealing with the co-cs mode technologies we are FORCED to do many of the right things, ie OOB control/management is forced, client/server relationships are always respected (and there can't be a wrapper behaviour), you can't 'merge' trails nor can you terminate them 1 hop too short, there are no QoS classes (this is another story of course about the illusion of DS).  However, you can do nasty things to the co-ps mode....and its from this basis PWs were spawned.  Whilst they stayed 1-hop many of the issues could remain latent......but not when they go multi-hop and have to be properly networked.  This PW layer network should never have been created......all we really want is a simple client/server relationship.....but that is not possible because of how MPLS has been defined.  And this is pretty serious stuff....because one of the (if not THE) key services an operator must be able to provide is a simple managed BW network builder capability, ie a functionally decoupled client/server relationship between the layer networks of 2 different operating parties....and if the client is an MPLS network and the server is an MPLS network.....well I am sure folks can figure out where this heads.

I'm sorry many IETF folks don't like ITU defined functional architecture....and that is a real shame.  Because if this was better understood then perhaps less mistakes would be made.

I really don't know where this PW stuff is going to end-up.....I've been of the view it probably passed the event horizon a long time ago and its too late now.  We could fix MPLS (its not PWs that need fixing these are just a symptom)......but is there the will?  But just think about it for a moment...why can't we have a co-ps mode technology run just like a co-cs technology as per GMPLS?....and what is THE key observation with GMPLS, ie there is no IP in the *traffic* data-plane.  And if this is good enough for GMPLS then why not for MPLS?  Indeed, the biggest problem with MPLS is that it treats IP, MPLS and 'other' clients all differently....and until that is understood then we will never have a good solution.

Its clearly doable, but is there the will?  There were 3 organisations proposing a need to develop 'transport MPLS' at the last SG15 mtg.  That is 1 way out of the current mess.  

regards, Neil

> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: 04 August 2005 11:38
> To: Harrison,N,Neil,JRD1 R; [email-masked]
> Agree Neil on this address mis-understanding - I have seen it
> multiple times. Many are confusing the use of NSAPs by the 
> management plane as requiring the support in a control 
> protocol. These NSAP addresses are very specific for the 
> management plane application (user or service provider), and 
> private. No different than a service provider using private 
> addressing for their internal network, a user will require the same.
> 
> Deborah
> 
> Behalf Of [email-masked]
> NH=> Interesting point you raise here.  Every layer network
> needs an addressing schema.  Indeed, even if you use v4 
> addressing in GMPLS for the *traffic* data-plane VC4 layer 
> network in SDH this is not the same addressing space as the 
> IP layer network v4 address space.  And of course the VC12 
> layer network also has its own address space, which could 
> also be v4.  And neither of these are the *same* as the 
> data-plane networks which carry their 
> control/management-plane protocols.  So addressing (like 
> routing) is not a single function spanning all layers.  And I 
> wish this was better understood because I think too many 
> folks still believe there is a 'common control-plane' running 
> from IP to Optics.....there can't be, it makes neither 
> technical nor commercial sense
> 
> MPLS is an odd-ball here as a layer network, but I don't
> really want to get into the nuances of the wrapper here 
> (though its a fairly serious problem IMO and also lies at the 
> heart of many other problems).
> 
> However, let me point this out.  We should never have created
> this PW layer network in the 1st place.  cl-ps(eg IP)!= 
> co-ps(eg MPLS) != co-cs (eg GMPLS) and that is just a fact.  
> I know the history of arch violations/errors why we have 
> arrived here and quite frankly its a mess....just looking at 
> the stuff regarding the VCCV breakout group tells you 
> something is very seriously wrong here.  However, having 
> created this unnecessary layer network then yes addressing 
> will have to be defined for it...and every other functional 
> component that a layer network requires will also have to be added.
> > 
> NH=> What do you want me to say?.....perhaps something like,
> 'well done for yet another major error'?  I remember when I 
> saw these 'addresses' being originally cooked-up saying to 
> myself.....this is going to create a serious problem 
> downstream.  Addressing is one thing you should pay great 
> attention to at t=0....if you screw it up you are stuck with 
> it for a very long time.  But hey, this stuff is built on a 
> whole pile of compounded mistakes so why just pick on this 
> one?  If you really want to fix thing you are going to have 
> to go back quite a long way.  It may simply not be worth it 
> now and perhaps folks should think of other ways to address 
> (no pun intended) this client/server service issue.
> 
> regards, Neil
> > 
> > Luca
> > 
> >

---

From: [email-masked]
Date: Fri, 5 Aug 2005 15:32:23 +0100

Whilst waiting for Luca to respond to Yakov's question I'd like to expand a little more on what I see are key operator requirements here and why the current PWE3 direction is really not addressing these.

The most important private service for a operator is a network builder capability.  This is, at essence, a client/server relationship where the client and server layers are functionally decoupled and need to be because they are owned/operated by 2 different parties.  All other 'value-add' services (such as a rfc2547 VPN say) should be able to build on this.....or putting this another way, a network builder capability and rfc2547 should not be mutually exclusive stovepipe solutions.

Now, let's look at GMPLS....this adds an OOB IP control-plane to the co-cs traffic data-plane.  And it's a great solution, because fundamentally GMPLS provides a network builder capability.  Note there is no ambiguity about the traffic data-plane traffic units....IP pkts (or other) can't suddenly 'materialise' here.  And its got all the right architectural behaviours in other respects too, ie no merging of trails, no terminating trails in the wrong place, no trail QoS classes (and thus no complex/worrying performance inheritance issues), true client/server hierarchy (eg no wrapper), simple fault/traffic/performance management.

However, as operators sun-set their old legacy technologies that provided either a true co-cs network builder capability using nx64k, E1/T1, etc, and also the facsimiles of these based on ATM and FR, a serious problem is emerging....we need a co-ps solution for doing co-cs at lower BW granularity (because ~140M VC4 is going to be the smallest true co-cs mode technology operating under a GMPLS control-plane).

Sadly, MPLS as-is can't step up to this role as it breaks the client/server decoupling rule, ie clients of MPLS are treated quite differently if they are IP, MPLS or 'other'.  Indeed, a whole new unnecessary layer network (seems almost like a new industry now!) has sprung up from this....it's called PWs.....and it's unfortunately generating a huge amount of erroneous/wasted effort.  You don't see any PWs in GMPLS do you?!  And this can carry IP, ethernet, ATM, FR, etc....anything in fact.  And we need exactly the same behaviour from MPLS....and most critically we need a co-ps_CBR behaviour.

I don't have the exact figures to hand, but we have a large and non-diminishing (growing in fact) customer requirement for this type of network builder service.  Further, its not just end-system customers....other operators (including ourselves) need this capability when we extend our networks and don't own the lower layer networks.  So please don't think this is something I'm pushing just for the sake of it....its a real and important service requirement. 

We are not the only organisation to spot this issue.  3 parties had proposals into the last SG15 meeting suggesting 'transport MPLS' should be developed.  This is not some new protocol, it's just careful selection from the MPLS parts-bin....and it looks a bit like this:
-	p2p and p2mp trail data-plane constructs only...so no merging (ie no LDP and PHP) and no stopping the trail 1-hop too short (ie no PHP)
-	consistent simple OAM irrespective of the client.....Y.1711 is ideal for the 'always-on' fault-management bits, but if you want to go and replicate this functionality some other way for the fun of it then fine.  LSP-Ping would now be very simple here and useful for 'on-demand' diagnostics, eg trail tracing.
-	given there are no 'misordering problems' in a properly done co network (like GMPLS say) there is no need for the TTL field.....so we could use that in more useful ways, eg having 1 bit for traffic or OAM payload indicate would be rather useful IMO
-	folks could tinker with lots of QoS/traffic classes if they liked, but a simple CBR behaviour is the most important (esp when selling a network builder capability to a customer and then wanting to manage it very simply).
-	we could copy the GMPLS model of using v4 addressing of the LSP trail access points (though I do think v6 should be considered as it is its own layer network), and run OSPF and RSVP-TE in an OOB control-plane.  Which also solves many security/stability concerns.  You could use the rather bizarre AGI/TAII/SAII addressing that was concocted for 'L2VPNs' (sic), but why bother?...we don't need to create a new 'PW layer network' any more so its not required....just copy the GMPLS model.

And that's basically it.  Now I would be very interested to hear from any other operators or vendors (esp) who might be interested in working on this with us.  One major vendor is already the editor for this work in SG15.  I can't see any good technical reason not to do this.  Folks who don't fancy this can of course carry on with the current PW stuff.

regards, Neil

> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: 05 August 2005 07:35
> To: Luca Martini
> Cc: Harrison,N,Neil,JRD1 R; [email-masked]; [email-masked]
> Subject: Re: [Pce] RE: [PWE3] Correction of my statement 
> regarding PCE. 
> 
> 
> Luca,
> 
> > Neil,
> > 
> Do you have some facts to support your claim wrt "major changes".
> 
> Yakov.
> 
> > 
> > Luca
> > 
> > 
> > >> significant changes to LDP? Frankly speaking I don't 
> really see why 
> > >> we should choose between LDP and RSVP-TE for MH PW sig, why not 
> > >> progressing both approaches? When explicit routing is 
> not required 
> > >> then use LDP, and if explicit routing is required use 
> RSVP-TE. This 
> > >> is what we are doing today for LSP signaling by the way...
> > >>
> > >> Best Regards,
> > >>
> > >> JL
> > > protocol....in
> other words you really only need one of them for providing 
> this function.  Why 
> an operator would wish to run multiple types of the same 
> functional component s eems unclear.  A 1 hop trail is a 
> degenerate case, ie its not a networked entit y......but IMO 
> it would seem rather silly just to have a different 
> signalling p rotocol for this special case, one may as well 
> use the one that applies for the  general case.  Minimising 
> functional components should also help minimise cost s, at 
> least as a general rule.  The other nice thing about using 
> the GMPLS deve loped spin of RSVP-TE is that it can be used 
> OOB....and that has to be a good t hing for 
> security/stability design considerations (though I am well aware MPLS 
> has not been designed like this, and that in GMPLS the co-cs 
> mode forces good d esign practice anyway).
> > > 
> > > regards, Neil
> > > 
> >

---

From: [email-masked]
Date: Fri, 5 Aug 2005 16:26:57 +0100

Note - Just 1 slight clarification which is not in what I wrote below.....if we wanted to keep LSP-Ping as-is we would need to keep the TTL field of course.  I can actually think of other ways to do tracing without this.....but I'll leave that as an aside for now.

regards, neil

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 05 August 2005 15:32
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Whilst waiting for Luca to respond to Yakov's question I'd 
> like to expand a little more on what I see are key operator 
> requirements here and why the current PWE3 direction is 
> really not addressing these.
> 
> The most important private service for a operator is a 
> network builder capability.  This is, at essence, a 
> client/server relationship where the client and server layers 
> are functionally decoupled and need to be because they are 
> owned/operated by 2 different parties.  All other 'value-add' 
> services (such as a rfc2547 VPN say) should be able to build 
> on this.....or putting this another way, a network builder 
> capability and rfc2547 should not be mutually exclusive 
> stovepipe solutions.
> 
> Now, let's look at GMPLS....this adds an OOB IP control-plane 
> to the co-cs traffic data-plane.  And it's a great solution, 
> because fundamentally GMPLS provides a network builder 
> capability.  Note there is no ambiguity about the traffic 
> data-plane traffic units....IP pkts (or other) can't suddenly 
> 'materialise' here.  And its got all the right architectural 
> behaviours in other respects too, ie no merging of trails, no 
> terminating trails in the wrong place, no trail QoS classes 
> (and thus no complex/worrying performance inheritance 
> issues), true client/server hierarchy (eg no wrapper), simple 
> fault/traffic/performance management.
> 
> However, as operators sun-set their old legacy technologies 
> that provided either a true co-cs network builder capability 
> using nx64k, E1/T1, etc, and also the facsimiles of these 
> based on ATM and FR, a serious problem is emerging....we need 
> a co-ps solution for doing co-cs at lower BW granularity 
> (because ~140M VC4 is going to be the smallest true co-cs 
> mode technology operating under a GMPLS control-plane).
> 
> Sadly, MPLS as-is can't step up to this role as it breaks the 
> client/server decoupling rule, ie clients of MPLS are treated 
> quite differently if they are IP, MPLS or 'other'.  Indeed, a 
> whole new unnecessary layer network (seems almost like a new 
> industry now!) has sprung up from this....it's called 
> PWs.....and it's unfortunately generating a huge amount of 
> erroneous/wasted effort.  You don't see any PWs in GMPLS do 
> you?!  And this can carry IP, ethernet, ATM, FR, 
> etc....anything in fact.  And we need exactly the same 
> behaviour from MPLS....and most critically we need a 
> co-ps_CBR behaviour.
> 
> I don't have the exact figures to hand, but we have a large 
> and non-diminishing (growing in fact) customer requirement 
> for this type of network builder service.  Further, its not 
> just end-system customers....other operators (including 
> ourselves) need this capability when we extend our networks 
> and don't own the lower layer networks.  So please don't 
> think this is something I'm pushing just for the sake of 
> it....its a real and important service requirement. 
> 
> We are not the only organisation to spot this issue.  3 
> parties had proposals into the last SG15 meeting suggesting 
> 'transport MPLS' should be developed.  This is not some new 
> protocol, it's just careful selection from the MPLS 
> parts-bin....and it looks a bit like this:
> -	p2p and p2mp trail data-plane constructs only...so no 
> merging (ie no LDP and PHP) and no stopping the trail 1-hop 
> too short (ie no PHP)
> -	consistent simple OAM irrespective of the 
> client.....Y.1711 is ideal for the 'always-on' 
> fault-management bits, but if you want to go and replicate 
> this functionality some other way for the fun of it then 
> fine.  LSP-Ping would now be very simple here and useful for 
> 'on-demand' diagnostics, eg trail tracing.
> -	given there are no 'misordering problems' in a properly 
> done co network (like GMPLS say) there is no need for the TTL 
> field.....so we could use that in more useful ways, eg having 
> 1 bit for traffic or OAM payload indicate would be rather useful IMO
> -	folks could tinker with lots of QoS/traffic classes if 
> they liked, but a simple CBR behaviour is the most important 
> (esp when selling a network builder capability to a customer 
> and then wanting to manage it very simply).
> -	we could copy the GMPLS model of using v4 addressing of 
> the LSP trail access points (though I do think v6 should be 
> considered as it is its own layer network), and run OSPF and 
> RSVP-TE in an OOB control-plane.  Which also solves many 
> security/stability concerns.  You could use the rather 
> bizarre AGI/TAII/SAII addressing that was concocted for 
> 'L2VPNs' (sic), but why bother?...we don't need to create a 
> new 'PW layer network' any more so its not required....just 
> copy the GMPLS model.
> 
> And that's basically it.  Now I would be very interested to 
> hear from any other operators or vendors (esp) who might be 
> interested in working on this with us.  One major vendor is 
> already the editor for this work in SG15.  I can't see any 
> good technical reason not to do this.  Folks who don't fancy 
> this can of course carry on with the current PW stuff.
> 
> regards, Neil
>