Subject: RE: Appropriate addressing [Was: Re: [Pce] RE: [PWE3] Correctionof my statement regarding PCE.]

From: [email-masked]
Date: Wed, 10 Aug 2005 10:26:06 +0100

Luca,  please also see my response to Scott.....but I need to make some additional points below.

Luca Martini wrote 10 August 2005 01:30
> 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.
NH=> We need to clearly separate the structure of an address form its layer network usage.  I can use v4 or v6 structured addresses in a any layer network data-plane.....they are not necessarily related to an IP cl-ps layer network.  So, for example, I can use v4 or v6 address structures for the VC12 and VC4 layers network in SDH.  And I can also use them (as you correctly note) for an IP network that I run OOB to control the VC12 and VC4 layer networks.  So here I have identified at least 4 layers network (ie VC12 and its control/management, VC4 and its control/management....and these are separate layer network systems please note) that are all essentially disjoint from each other.  And none of these has anything to do with any other IP layer network (eg Internet)....and that is for very good reasons!

Aside - You may want to look at draft-ietf-ccamp-gmpls-addressing-01.txt that attempts to clarify the way addresses are used in GMPLS wrt to what I am pointing out above.  But to be honest it does not do that good a job and is a bit of a confusing read IMO.....however, the authors have at least attempted to get to grips with these different uses of addresses.
> 
> 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.
NH=> Absolutely right....and it MUST NOT have anything to do with it.  None of this stuff has anything to do with the Internet in reality....did you seriously ever think it did?

> 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 )
NH=> That is correct.  But on the other hand I would very strongly caution against creating addressing structures without proper consideration.....as I noted in an earlier mail, once you create an addressing structure it is very hard (understatement) to change it later.  But hey, we should not even be creating this unnecessary PW layer network in the first place.....but you will no doubt be pleased to hear I don't have the energy to go over again how it got like this in the 1st place.

regards, Neil
> 
> Luca
> 
> 
> 
> 
> 
> Adrian Farrel wrote:
> > [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,
> > 
> > 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
> > 
> > 
> > [email-masked] wrote:
> >> 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
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: [email-masked]
Date: Wed, 10 Aug 2005 10:42:49 +0100

Colleagues,

See inline (I've snipped the rest).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
>

This isn't always true IMO.

For MS-PWs, an IP control plane is used to control a MS-PW user plane
regardless of what technology is used to transport the MS-PWs (as MS-PWs
form a separate layer network, and are not simply an adaptation
function).

For SS-PWs transported over MPLS, an IP control plane is used to control
an MPLS user plane (as MPLS is a separate layer network to IP regardless
of which 'mode' or features of MPLS you enable/disable).

So in at least these two cases an IP network is not being used to
forward traffic, it is only being used for control protocol information
in the same way as GMPLS uses IP control plane that is separate to the
GMPLS user plane.

Further - I agree with Scott's comments re: naming & addressing, and
agree that PWE3/MS-PW needs a way of addressing MS-PW control entities
and a way of naming(/addressing?) MS-PW end-points.  Both these sets of
identifiers could be based on IP addresses (or the IP address
format/syntax) but they don't exist in the same identifier (i.e.
name/address) spaces, one set exists in the IP control plane identifier
space and the other exists in the MS-PW user plane identifier space.

Ben