Subject: RE: Appropriate addressing [Was: Re: [Pce] RE: [PWE3] Correction ofmy statement regarding PCE.]

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

Scott,

This is largely correct but there are few key points I want to make
here....please see below.

Scott wrote 10 August 2005 02:44
> 
> 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.
NH=> That is correct.  But we have to be more precise that this when
considering the co and cl modes.  In the co modes the (visible/external)
'address' is associated with the access points that bound the largest
G.805 subnetwork, ie the network.  These appear in a G.805 func arch
sense just above the trail termination point.  However, all the internal
CPs (connection points) are also 'addressable'.....but these are
internal addresses.  Further, when one has the co-cs mode there are
least 2 data-plane networks in the same networking system....this is a
FORCED requirement of the co-cs mode.....however for good design
practice (eg security/stability/resilience considerations) it should
also apply to the co-ps mode too.  I tend to refer to these as the
traffic data-plane network and the control/management data-plane
network.  And each of these networks have their own addressing spaces
which are not related.....there is of course 'dialogue' between the 2
networks (else there would be no ability to affect trail set up in the
traffic data-plane) but in terms of direct traffic connectivity this is
not allowed.

cl-ps networks are different....these are based on flow domains (see
G.809) and don't have the notion of CPs but rather Flow Points.  IP has
chosen 1 form of addressing it's subnetworks (which is a different
meaning to G.805 subnetworks).  However, even in a cl-ps mode network we
could still have an OOB control/management network....its just that
usually this is not done.
> 
>   - ways of addressing PEs, so that we can send control or mgmt
>     messages to them to talk about PWs.  These are clearly IP
>     addresses.
NH=> But these do NOT necessarily connect to the public Internet or
other IP networks in general.  In fact, it would very beneficial (for
the reasons I noted above) to have the control/management data-plane
network completely disjoint from the traffic data-plane network....and
here I for sure would not want these 'IP addresses' accessable from the
Internet (or indeed any other organisation's IP network).  And to be
accurate here a v4 or v6 say address is simply an address
structure....it does not have to be tied back to a cl-ps mode layer
network.  I can use such an address structure for identifying the access
points in the traffic data-plane of an SDH VC4 layer network
say......and what has this got to do with either the Internet or indeed
IP (in a layer network sense)?.....nothing is of course the answer.
> 
>   - 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.
NH=> We could have gotten away with this to a large extent if PWs had
stayed single-hop, ie not a networked entity.  Once they go multi-hop
and get networked in their own right then I'm sorry but we have just
created a new layer network.  In fact you sort of hint at this yourself
right at the end below when you say "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."......and if you recall I have been saying exactly this for
some time now.  And the address structure that is being bestowed on this
new PW layer network is that defined by the AGI/SAII/TAII stuff.

regards, Neil
> 
> 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 10:23:13 -0400

Scott 

I largely agree with you comment about names. I find the following
useful to categorize identifiers into addresses and names spaces.  

For quite some time I have been advocating in a network there should
only be one true routable address scheme.  However there may be many
name spaces that have an address format and are indistinguishable from
an address from a user point of view. This give the appearance of
supporting multiple addresses while maintaining the value of a single
address plan. 

To clarify this:

>From a Carrier or Service Provider view a single addressing scheme with
local and global scope. The global identifiers are unique across
providers. Also you have one or more naming schemes with a private
(local) scope from the provider view. Many of these names are in a
standard address format and others are not. 

>From a customer (of the carrier) view you have an addressing scheme
which may have global or local scope. If it is global some entity
assigns the address, if it is local scope it may take a number of
standard address formats.  If is local the customer has a private space.
The customer may view both local and global as true routable addresses
in their native format. If the customer is large they may have their own
Naming schemes as well. 

When it comes to carrier control addresses these should have an address
scheme in local scope which that carrier has flexibility. When a carrier
must provide a global standard format address for a service the
component would then have at least two identifiers the local address and
the a name in global address format. This separation give the best
flexibility. Further I find that components also have additional
identifiers such as hierarchical names which are used for maintenance
operation. 

Most of the confusion I see in these discussions comes when a component
that should have both a local scope identifier and global scope
identifier tries to use a single address format for the multiple
functions (and often calls this an identifier an address). 

Regards,
Don   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott W Brim
> Sent: Tuesday, August 09, 2005 9:44 PM
> To: [email-masked]
> Subject: Re: Appropriate addressing [Was: Re: [Pce] RE: 
> [PWE3] Correction ofmy statement regarding PCE.]
> 
>