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

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

JL wrote 04 August 2005 10:08

> Hi Luca
> 
> Please see inline,
> 
> > -----Message d'origine-----
> > 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.
> > 
> > 
> > 
> > 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???
> > > 
> > 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.
> 
> 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

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

---

From: Luca Martini <[email-masked]>
Date: Thu, 04 Aug 2005 03:37:36 -0600

Neil,

Don't you think that having an appropriate addressing scheme for the 
multi segment PW is necessary ?

If so, it would mean major changes to RSVP-TE which only supports ipv4 
and ipv6 addressing right now.

Luca

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 04 Aug 2005 23:35:16 -0700

Luca,

> and ipv6 addressing right now.

Do you have some facts to support your claim wrt "major changes".

Yakov.

> > 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 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).
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>