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

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

---

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).

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Aug 2005 17:49:04 +0100

[Dropped PCE WG off the circ list]

Luca,

We need to think very carefully about the "appropriate addressing scheme".

What are the deficiencies of IP addressing for use in the control plane
that you see being raised by PWs? (Care - this is a trick question!)

As Neil points out, control plane addressing is not management plane
addressing, and might not be data plane addressing.

When you say that RSVP-TE would need "major changes" to support addressing
other than IPv4 or IPv6 I suspect you have not been following CCAMP too
closely.

Could you please separate the requirements form the solution? Let's have a
nice clear statement of the addressing requirements for PWs. Once we have
agreed on them we can move forward with the protocol solutions/extensions.

This is not a statement of support or opposition to any proposed solution.

Cheers,
Adrian

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 04, 2005 10:37 AM
Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE.

Neil,

Luca

[email-masked] wrote:
> 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).

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

---

From: Luca Martini <[email-masked]>
Date: Tue, 09 Aug 2005 18:29:43 -0600

Adrian,

Keeping out of the solution proposals...

I would think that the requirements could be spelled out as follows:

- Separate topology ( From IP network ) for L2 that is advertized in a
routing protocol ( BGP )
- Ability to aggregate reachability.
- No limitations on address allocation. ( outside of the aggregation
rules/route selection rules )

The main difference that I can see from the CCAMP , is that in this case
we are using the IP network to forward traffic ... while the CCAMP GMPLS
IP network is only used for control protocol information.

As far as the deficiency of IP addressing question below: I have no
doubt that we can overload the IP address and use it for L2 as well, but
then it is no longer the same IP addressing as allocated for internet
use. Are we willing to accept the difference ? and not confuse the
addressing of IpV6 with L2 PW addressing ?
Who is going to manage the global allocation ? ( This is a general
question that we need to consider no matter what address scheme we use )

Luca

---

From: Scott W Brim <[email-masked]>
Date: Tue, 9 Aug 2005 21:43:37 -0400

On Fri, Aug 05, 2005 05:49:04PM +0100, Adrian Farrel allegedly wrote:
> What are the deficiencies of IP addressing for use in the control
> plane that you see being raised by PWs? (Care - this is a trick
> question!)

Let's be clear what we're talking about first.  "Addressing" can be a
vague word.  I think of "addresses" as names that have topological
significance in the layer network in question.

  - ways of addressing PEs, so that we can send control or mgmt
    messages to them to talk about PWs.  These are clearly IP
    addresses.

  - ways of naming PW endpoints and associating PW endpoints with ACs,
    in those control or mgmt messages.  These are not (necessarily)
    "addresses", in that they do not (necessarily) have topological
    significance, so let's not call them that.

The first is easy, the second is where you need an independent naming
scheme (although names might initially be generated from IP
addresses).  

> When you say that RSVP-TE would need "major changes" to support
> addressing other than IPv4 or IPv6 I suspect you have not been
> following CCAMP too closely.

CCAMP has a similar issue.  The control nodes (PEs in our case) are IP
addressable, but the control messages have to be enhanced to name the
forwarding path nodes.  

If you want to get formal, in a MS-PW environment the PW packets are
not forwarded in the IP layer, they are forwarded in the MS-PW layer.
MS-PWs are more than just adaptation.

swb