RE: [PWE3] RE: Appropriate addressing

[[e-mail]]

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



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Chris Metz (chmetz)
> Sent: 10 August 2005 17:55
> To: Spencer,R,Richard,XDE73 R; Scott Brim (sbrim); [e-mail]
> Subject: RE: [PWE3] RE: Appropriate addressing
> 
> 
> 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> 

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

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