Subject: RE: [PWE3] Draft Charter - opening

From: [email-masked]
Date: Thu, 21 Jul 2005 13:02:12 +0100

Scott....mainly agree....but 1 point below.
> > 
> >             migrating to a single IP or MPLS based packet
> >             switched network (PSN)
> > 
> > Why are we keeping up the pretense of IP and MPLS?
> > The IP part is now handled by the l2tpext unless you are
> refering to
> > RFC4023 PWs or TDMoIP's use of UDP ports. ... and BTW, there is a
> > statement about division of labor with l2vpn, but no 
> similar statement
> > about l2tpext.
> 
> This isn't a statement about the scope of the WG, it's about
> what network operators are doing (they are migrating to IP 
> *and/or* MPLS), so which WG handles what is not an issue 
> (that comes later).
NH=> Any sensible network operator should, I hope by now, be figuring
out that they require all 3 networking modes working in concert.  IP is
fine and very important.  SDH/OTN (read as 'GMPLS' here) is fine (its
jolly hard to screw-up the co-cs mode....could use smarter components
IMO however).  Most of the problems revolve around MPLS and the co-ps
mode.  I have spelt these out many times in the past.

However, when you say above Scott 'they are migrating to IP *and/or*
MPLS' above this is not accurate IMO....there is no 'OR' option here.
IP alone 'yes', MPLS alone 'no'.....and therein lies one of the base
problems. A client of MPLS is treated very differently dependent on what
that client is, ie:
-	if IP it can be a null encaps client OR a 'peer' PDU on some
I/F.....this can't be a very good idea if you think about it (esp what
it means in func arch terms)
-	if MPLS it is given the wrapper treatment.....which is a problem
all of its own, eg the topology on the fly illusion and the inabilty to
do proper client/server (ie functionally decoupled) layer network
relationships between the MPLS networks of 2 indepenmdent operating
parties......and as a consequence of this a whole bunch of folks are now
blundering into 'MPLS NNIs'...we really DO NOT want these as there are
no 'MPLS' public services (Andy Malis and MFA please take careful note);
-	if 'other' it is given the PW adaptation treatment.....which is
yet another symptom/problem all of its own as we are creating a new (PW)
and unnecessary layer network here (sadly).

So I am, to some extent, with Yaakov on this....MPLS is currently
neither fish nor fowl when trying to classify it and use it (just look
at how the G.8110 MPLS func arch has been forced to model it...I know
because we (Alan McGuire of BT) wrote it...it just shows what it says on
the rfc tin).  And yet, by necessity (even if those of religious
persuasion shriek in protest), XoverIP must diverge from XoverMPLS...and
of course this is what is actually happening anyway.

I wonder how many folks reading this truly grasp what I am talking about
here?  If you do, and esp if you are an operator, you should be fairly
worried about what your suppliers are currently planning to cook-up and
how you are going to do network builder services (between the MPLS
networks of 2 different parties) when all other technologies that
provide these today are sunsetted.  However, my reading of the operator
community (based on inputs to date...mainly lack of) is that (i) most
don't grok this stuff and (ii) those that do are too scared to
acknowledge it and try and do something about it.  However, these issues
are pretty fundamental and they are not going to 'go away'.....we can
either keep blindly digging in the current/same direction or we can face
up to the issues and start to work them out properly.  I sense its a bit
of 'we hear you Neil and some of us get this, but boy what a problem we
have to get this lot back on track now without losing face...and of
course sunk investments'.

Well, all I can say is 'you have to start somewhere', even if you have
already gone many miles in the wrong direction.....and this has to begin
with a lot more honesty (ideally based on a sound grasp of functional
arch...as this helps us stop making mistakes).  But what teeth does this
WG have to go back to 'higher command' and say 'we can't work on this
stuff because the base networking protocols we have been given are
broken'.  I'm actually serious about this.  You cannot solve things here
in this WG unless:
-	LDP and PHP (and its ECMP bedfellow) are deprecated
-	IP and MPLS are NOT regarded as the 'same' layer network
(painfully obvious IMO).....which is essentially Yaakov's point
-	and a corollary of this is that MPLS access points are given
their own addressing
-	we take internal control/management OOB 
-	we adress the wrapper problem
-	we do NOT create this unecessary PW layer network
-	we add simple/complete OAM at the MPLS LSP level.....not in some
artifical PW layer

I'll close with this observation....if MPLS cannot step-up to this then
other technologies will step-in (ethernet is esp promising in this
respect IFF it is done properly).  BT and 2 large vendors have already
proposed (in SG15) there is a need to develop 'transport MPLS'......so
its more than me who sees the above.

regards, Neil

> 
> 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: Scott W Brim <[email-masked]>
Date: Thu, 21 Jul 2005 09:11:49 -0400

On 07/21/2005 08:02 AM, [email-masked] allegedly wrote:
> that client is

and then you discuss how MPLS clients are treated.  That's much
further down in the charter.  This paragraph is about what people are
using for backbone server layer technology.

> the rfc tin).  

First, this has nothing to do with rechartering.  Second, as I said to
Alan, this shows brittleness and inappropriateness of the model at
least as much as it shows problems with MPLS as deployed.  It's good
that the unified model will have some more flexibility.

The rest is about "MPLS as transport", which is a fine "solution
scenario" for a particular use of MPLS and PWE3, but as far as I can
tell doesn't change the charter.

I'm done.

Scott