Subject: [PWE3] RE: Appropriate addressing

From: [email-masked]
Date: Wed, 10 Aug 2005 12:41:21 +0100

Scott,

I agree that addressing means different things to different people, but
I would argue that PW endpoints identifiers are addresses and that /32
PE loopbacks are actually more like names. In general, an address should
provide information about location, just like a postal address does. A
name on the other hand uniquely identifies an object, but is independent
of location, e.g. a SIP address or URL. For example, a user can send an
email to someone if they know the other persons email address (name),
but this is only possible because DNS servers are used to determine
which email server the email should be sent to, and IP routing is used
to determine where the server is located in the network based on the
server's IP address.

In the case of /32 loopbacks used in IP/MPLS networks, they do not
provide any information about location, they just uniquely identify a
PE. Packets can be sent to PE's using a /32 loopback address, but this
requires every node in the network to have a route to every /32 loopback
address that it needs to send packets to. A /32 loopback is comparable
to a MAC address, neither provides information about location and they
both rely on every node in the forwarding path containing information
about the location of each address, e.g. address X is located behind
port/interface S2.

In the case of PW endpoint identifiers, these do have topological
significance (at the PW layer) because they need to uniquely identify
the location of the PW endpoints for OAM/routing/signalling purposes. In
the SS-PW case, the location of a remote PW endpoint (i.e. which PE the
endpoint resides) can be determined (implicitly) based on the remote PE
address used for the signalling session. In the MS-PW case, the remote
PW endpoint location cannot be inferred from the signalling session and
therefore the PW endpoint location must be signalled (explicitly). If
for example a PW endpoint address is of the format [AS#]+[PE
loopback]+[PW ID], then the address does provide information about
exactly where the PW endpoint is located, i.e. which AS within the
network, which PE within the AS, and which AC within a PE. This is
analogous to say [Street name]+[House#]+[Person's name] in the postal
address case.

As expressed by Neil/Ben, PW addresses belong to a different address
space than the L3 IP forwarding addresses, but this doesn't mean that
they are not addresses. I agree that what constitutes an address is
debateable, but PW endpoints need to be uniquely identified and located.
Therefore, I would say that PW identifiers should be addresses, not
names.

Regards,
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Scott W Brim
> Sent: 10 August 2005 02:44
> To: [email-masked]
> Subject: Re: Appropriate addressing [Was: Re: [Pce] RE: [PWE3]
> Correction ofmy statement regarding PCE.]
> 
> 
> On Fri, Aug 05, 2005 05:49:04PM +0100, Adrian Farrel allegedly 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!)
> 
> 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
> 
> _______________________________________________
> 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: "Don Fedyk" <[email-masked]>
Date: Wed, 10 Aug 2005 12:17:59 -0400

Hi Richard

Please see my note to Scott and some comments inline:

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> 
> Scott,
> 
> I agree that addressing means different things to different 
> people, but I would argue that PW endpoints identifiers are 
> addresses and that /32 PE loopbacks are actually more like 
> names. In general, an address should provide information 
> about location, just like a postal address does. A name on 
> the other hand uniquely identifies an object, but is 
> independent of location, e.g. a SIP address or URL. For 
> example, a user can send an email to someone if they know the 
> other persons email address (name), but this is only possible 
> because DNS servers are used to determine which email server 
> the email should be sent to, and IP routing is used to 
> determine where the server is located in the network based on 
> the server's IP address.
> 
> In the case of /32 loopbacks used in IP/MPLS networks, they 
> do not provide any information about location, they just 
> uniquely identify a PE. Packets can be sent to PE's using a 
> /32 loopback address, but this requires every node in the 
> network to have a route to every /32 loopback address that it 
> needs to send packets to. A /32 loopback is comparable to a 
> MAC address, neither provides information about location and 
> they both rely on every node in the forwarding path 
> containing information about the location of each address, 
> e.g. address X is located behind port/interface S2.

Correct these are carrier local identifiers in IP address format. 

> 
> In the case of PW endpoint identifiers, these do have 
> topological significance (at the PW layer) because they need 
> to uniquely identify the location of the PW endpoints for 
> OAM/routing/signalling purposes. In the SS-PW case, the 
> location of a remote PW endpoint (i.e. which PE the endpoint 
This is where I would say they could have both a local identifier as
above and a global identifier in another format. 

> resides) can be determined (implicitly) based on the remote 
> PE address used for the signalling session. In the MS-PW 
> case, the remote PW endpoint location cannot be inferred from 
> the signalling session and therefore the PW endpoint location 
> must be signalled (explicitly). If for example a PW endpoint 
> address is of the format [AS#]+[PE loopback]+[PW ID], then 
> the address does provide information about exactly where the 
> PW endpoint is located, i.e. which AS within the network, 
> which PE within the AS, and which AC within a PE. This is 
> analogous to say [Street name]+[House#]+[Person's name] in 
> the postal address case.
It depends what you want to address the component for.  PWE uses IP
loopback as a local address for resolving the node. If it is the end of
a PW and you want to attach a frame relay service to it you should have
a global or local X.121 address format which is treated as another name
space for this component.  But all the while, packets in the MPLS
network are routed with one address plan, in the case of MPLS, this is
the carrier IP address plan. 

> 
> As expressed by Neil/Ben, PW addresses belong to a different 
> address space than the L3 IP forwarding addresses, but this 
> doesn't mean that they are not addresses. I agree that what 
> constitutes an address is debateable, but PW endpoints need 
> to be uniquely identified and located. Therefore, I would say 
> that PW identifiers should be addresses, not names.

An address in any other context is simply a name in a standard address
format.  The network provider uses the PE loopback as an address but the
PW may have another name in a another address format which the endpoint
uses. 

Regards,
Don

---

From: "Chris Metz \(chmetz\)" <[email-masked]>
Date: Wed, 10 Aug 2005 12:55:16 -0400

All-
It is precisely for the reasons spelled out by Scott, Luca, Neil, et al.
that:

http://www.ietf.org/internet-drafts/draft-metz-aii-aggregate-00.txt

was cooked up. Clearly we need a PW end-point "name" or "address space"
with the following properties:

- aggregatable

- flexible enough to accommodate (if desired) familiar/known address
structures (understanding of course
that they are completely separate from the whatever network layer
addressing scheme is in place). 

- option for global uniqueness

The actual field formats will change a little with some different names
but essentially
can accommodate the canonical structure described by Richard below.  

Chris   

<snip>

>for example a PW endpoint 
> address is of the format [AS#]+[PE loopback]+[PW ID], 

<snip>

---

From: [email-masked]
Date: Fri, 12 Aug 2005 11:58:35 +0100

Thanks Chris....I have had a look at the draft.  What you are
essentially doing here is describing a new addressing structure.  You
could apply this to ANY layer network of course.  What you intend here
is to apply to a new layer network....the PW layer network.  The fact
this is supported by some label-swapping co-ps technology....let's us
call it MPLS....is incidental to the point, eg I could apply this
addressing structure to ATM, OTN, SDH, whatever, access points.  And I
could then ask the GMPLS folks to adopt this (which would be silly IMO,
but it's a possible option).

The key point folks need to wake-up to here is that we will now have 2
co-ps networks, viz:  (i) regular MPLS layer and (ii) new PW layer.  And
they will be *different* layer networks.....let's be clear on that
point.  So each will require the full set of functional components to
make it work.  It's not clear to me folks have fully thought through the
implications of this.  And what I find most disturbing is that this is
not necessary IMO.....we should only require 1 target co-ps layer
network.

This nearly happened a few years wrt GFP.  GFP is an adaptation function
required to align/delineate client traffic units in a co-cs server
payload (when the client traffic units are NOT self delineating).  Some
folks then said 'what if we add OAM to GFP?.....and maybe other
functions?'....and very soon one could see GFP being turned from an
adaptation function into the basis of a new layer network.  Fortunately
sanity prevailed and we stopped this before it got out of hand.
However, this is precisely the course we are on here......and maybe its
going to take a while for this point to be understood?

The operator community really wants to think this one through very
carefully....we have enough layer networks as it is and don't need any
more.  The real problem that does not seem to be understood very well
here is that we already have MPLS and THIS should be the target co-ps
mode.

Anyway.....let me have one last go at trying to explain what I mean (and
then I'll probably give up.....I'm on leave next week anyway so you'll
definitely get a break from me then!):

-	Whenever we have created the topology of some arbitrary layer
network X say, we have (perhaps unconsciously) always relied on the fact
that the link connections of layer network X can be provided by all
sorts of server layer trails.  What I mean by this is that we have never
consciously assumed that XoverY and XoverZ are in any way related at the
adaptation level.....in other words Y and Z are completely independent
of each other (as layer networks), and this also implies the
client/server relationships between X_and_Y and X_and_Z are transparent.
Indeed, this fundamental G.805 (client/server) relationship is the
reason the phrase 'IP over everything' works, ie we carry the IP client
layer *transparently*, and quite independently of the server.

-	Now when we come to PWs and MPLS this fundamental 'law of
networking' seems to have been forgotten/broken.  It is not broken in
GMPLS however.....this can carry all manner of clients and we see no
need for some additional networked 'PW' adaptation function here do we?
Have folks really understood why this is I wonder?  And please remember
what nearly happened to GFP as I noted above.

-	The base problem with PWs is that some folks thought (once upon
a time) it would be really sensible if XoverMPLS was the same as
XoverIP.  This can't ever possibly be true in practice, but I can see
the erroneous thought process at work here....and of course this is the
IETF so we have to do this don't we? (not so with GMPLS please note).
This is the root cause of the problem.  However, whilst some folks may
strive to make the adaptation here common (and folks sure as anything
have) IP!=MPLS as a server layer technology.....there are fundamental
differences in mode/behaviour, and the functional components (eg
signalling) differences bear witness to this.  If MPLS is NOT different
to IP then why does it exist at all?  And I could say exactly the same
for GMPLS.  The deeper problem here is, of course, that there is a major
reluctance to accept the basic truth that we have different networking
modes (ie cl-ps!=co-ps!=co-cs) and we should not attempt to try and
treat them the same.  If folks can't or won't accept this then we have a
very serious and intractable networking problem on our hands that will
not be solvable.  So, on the assumption we are prepared to accept some
base networking truths here, it would be quite silly to assume
XoverMPLS==XoverIP.  The only sensible architectural treatment here
would be that which I mentioned in the 1st bullet above, ie MPLS and IP
provide *independent* network partitions of server layer trails for link
connections in layer network X.  But, unlike the GMPLS case (where the
co-cs mode forces these architectural truths anyway), this was clearly
not good enough and has been fiercely resisted....even though it is
clearly architecturally wrong.

-	So what have we got?  Well, let's look at MPLS.  This SHOULD be
a co-ps layer network in its own right.  It SHOULD look like GMPLS in
fact.  But it doesn't.  MPLS does not treat its clients in the same way.
An IP client can either be null encapsulated or a peer of an MPLS PDU on
the same interface.  An MPLS client is given the 'wrapper' treatment wrt
encapsulation (which is  a major problem in its own right).  And
'anything else' is given a PW encapsulation.  Now, if I don't know if
this is obvious right now but this is creating a serious architectural
problem.  Fundamentally it means MPLS cannot be decoupled from IP in the
*TRAFFIC* data-plane....now contrast this with GMPLS where this is
clearly not the case.  So our problems start here.  They are compounded
of course by LDP/PHP/ECMP which makes traffic/fault/performance
management of MPLS as a layer network almost intractable, but that is an
adjunct story.

-	So we have ended up with the adaptation of XoverIP and XoverMPLS
as 'similar'.  This would be OKish if we then left it at that.  And
whilst PWs remained SH one might be able to live with problems that have
been created.  However go MH and these problems are no longer hideable.
In summary, we have created a new PW layer network operating between
some client X and the real networking partitions of IP or MPLS.  And, as
a by-product of this, it seems quite natural to suggest we can interwork
the XoverIP and XoverMPLS peer partitions.  This completely contradicts
what was mentioned in the 1st bullet above.  And you see the
consequences of this in things like the OAM Mapping stuff.  It's just
plain wrong.  We should not be mapping defects in some client layer X
into indications in some PW server layer....this is like saying if I
have defects in an ATM layer carried over SDH I'll tell the SDH layer
network....and then perhaps the SDH layer with tell the OTN
layer....etc.  This is clearly madness and it breaks all the rules of
client/server relationships.  And I do find it most peculiar that such
rules are almost mandated 'where they suit' and yet can be broken almost
at will where they don't.  

Ok let's get to the punch line now......folks can carry one with where
they are currently at (and I don't suppose for one moment anything I say
is going to change that) but I hope I have at least explained why we
have been brewing up some fairly serious problems here.  And there is a
key operator point that I have mentioned several times before:  Even if
I ignore the difficult operational traffic/fault/performance problems
posed by some spins of MPLS, operators need a network builder capability
in the co-ps mode.  Now MPLS as-is is simply not able to step up to that
requirement.  And something needs to be done about that.  The answer
does not need to be MPLS.  Take a leaf out of the GMPLS model.....whilst
this may not be perfect (and indeed the choice of
addressing/routing/signalling components are not prescriptive) the right
architectural framework is forced.  I can apply an OOB
control/management plane to ANY pkt technology and make it look co-ps
(even IP), so if MPLS cannot step-up to the role maybe other
technologies can.

regards, Neil

> Behalf Of Chris Metz (chmetz)
> Sent: 10 August 2005 17:55
> To: Spencer,R,Richard,XDE73 R; Scott Brim (sbrim); [email-masked]
> Subject: RE: [PWE3] RE: Appropriate addressing
> 
> 
> All-

- aggregatable

- flexible enough to accommodate (if desired) familiar/known address
structures (understanding of course that they are completely separate
from the whatever network layer addressing scheme is in place). 

The actual field formats will change a little with some different names
but essentially can accommodate the canonical structure described by
Richard below.  

Chris   

<snip>

<snip>