RE: [PWE3] RSVP MS-PW ? HOW?

Hi Luca....
> 
> WG,
> 
> I have many questions about the use of RSVP for MS-PWs. The current 
> draft (draft-raggarwa-rsvpte-pw-03.txt) contains a lot of discussion 
> of why we should use RSVP, but does not contain detail on how to use 
> RSVP to signal PWs. In the IETF we standardize protocols and not 
> arguments.
NH=> Its kind of nice to know WHY you are doing them of course.

> I still claim
> that this draft is not ready to be a WG draft, as it does not 
> contain a real complete protocol definition that meets the 
> stated requirements.
>  
> Let's look at different points that would have to be explained.
> 
> Traffic engineering of the PW layer has not been a clear
> requirement, however I believe that traffic engineering of an 
> MPLS network used to carry PWs is a requirement.
NH=> TE is a euphemism for 'create trails' when applied to THIS layer
network....however the topology of THIS layer network is actually
created by (trails in) a server layer....so TE works on different
timescales in each layer network.  Something I am not sure seems that
well understood.

The nature of MPLS as-is is why the PW layer network has come about.  If
you have 2 different co-ps layer networks you are going to want to
create trails in them both....quite independently.  So you are raising a
non-argument IMO.  The right (but completely unpalatable argument) is to
point out that IF MPLS had been designed to handle all clients the same
(ie inc IP) there would have been no need to create the PW layer network
at all.  So you have set off down the wrong road and it almost does not
matter which signalling protocol is now selected as the resulting arch
is still wrong. It's going be really interesting to see just how far
this stuff can be stretched before it goes bang and folks see the real
underlying problem here.
> 
> In today's deployments RSVP-TE is used to setup MPLS tunnels
> that carry PWs.  These tunnels are sometimes dedicated to PWs, 
> and are traffic engineered in the MPLS network along with 
> other MPLS tunnels that may be used for other purposes. One 
> of the main parameters used for TE is bandwidth utilization.  
> If we are proposing to traffic engineer the PW layer itself, 
> then we would presumably be able to select a certain subset 
> of statically pre-configured MPLS-TE tunnels to carry the PWs 
> and reserve the utilized bandwidth once the PW is signaled.
NH=> Er yes Luca...it's called a client/server relationship and we have
been doing them for a good few decades already.  Have you ever
considered what the link connections in an IP network are?

> Traffic engineering of PW would mean that S-PEs are selected
> based on available bandwidth to reach them. The question is 
> why?  We already traffic engineered the MPLS tunnels across 
> the MPLS network, why should be make this network an order of 
> magnitude more complicated by traffic engineering PWs on top 
> of already traffic 
> engineered tunnels?
NH=> Because some folks don't understand layer networks and networking
(but think they do) is the trite answer....they see the world as 1 big
flat network...it really is not like this.  The link connections in
layer N are trails in layer N-1 (and so it recurses to the duct).  So an
end-end PW trail (ie single entity) goes over *many* server layer MPLS
(other) trails....since each PW link connection is a MPLS (other) server
layer trail.  This means the PW trail traffic requirements need mapping
to many MPLS (other) server layer trails.  General observation:  When
the server layer is co-cs or co-ps_CBR performance inheritance is a
non-issue....and the converse also holds...so this one is also waiting
to bite you.

Go talk to the GMPLS folks as they were FORCED to see the client/server
relationship of networking because the co-cs mode does NOT allow you to
get many things wrong (all to do with the nature of labels and
Information Theory at a deeper level).  Some working on GMPLS may not
like the fact that multiple disjoint layer networks exist (spoils the
'single control-plane IP to optics' flawed vision), but the co-cs mode
means recovery to doing it right is not jeopardised

I have been trying to get this group to face up to the direction it has
been heading in for a couple of years, and all that is happening now is
that there is a slow waking-up to the consequences of creating a new
co-ps layer network above IP/MPLS..... and you seem surprised at its
consequences.  Well don't be, you now need to replicate ALL the
functions a co-ps mode layer network requires.  
> 
> I think that TE of PW themselves is not a useful feature. For 
> example, if an MPLS-TE tunnel runs out of available 
> bandwidth, we can simply make it bigger, by re-signaling the 
> RSVP-TE LSP with new parameters.
NH=> This shows a lack of networking understanding IMO.  A client layer
trail is supported on MULTIPLE link connections, each of which is
supported by a DIFFERENT server layer trail, ie you have to re-engineer
each and every one of the server layer trails.  Now go and put your head
round this for ANY pair of network relationships between any types of
layer network and follow you arguements down to the duct (I'll come back
on this point directly below).  You can't just go round 'creating BW at
will' in server layer networks.....there are different time-constants
and economics at play here (this is old 'topology on the fly' chestnut).

> This point applies 
> regardless of what protocol is used to setup the PW: the PW 
> layer itself should NOT be traffic engineered.
NH=> You completely miss the point.  Just step through your argument
recursively.  I have layer network N.  You say I don't need to TE this
because this is done at layer network N-1.  OK....but hang on, I don't
need to TE layer network N-1 as this is supported by TE in layer network
N-2....and so on until the ONLY layer network that requires TE is the
fibre/duct....that is the logical conclusion of your argument!  And I do
hope you can see how flawed it is.
> 
> There are two stages required in traffic engineering an MPLS network:

> 
> First a constrained shortest path calculation is performed to 
> select a path through the network.
NH=> Which 'network'?  Not sure if you realise, but the key requirement
of the arguments below is that MPLS MUST be TE'ed.  So you cannot use
LDP MPLS (or indeed IP) as a server.  Are you aware this is a logical
conclusion also?

> This path is calculated 
> based on a database that gives a picture of all available 
> links and resources on each link in the network.
NH=> Which 'network' are you now talking about...MPLS or PW?  Assuming
you are talking about the MPLS layer network then this is not
sufficient.....EACH link of the PW link connections needs a SEPARATE
MPLS trail creating as its server.  These MPLS server trails MUST be in
place before we can route a PW trail...in fact its these MPLS trails
that create the PW layer network topology.

And you can recurse this, ie what creates the MPLS topology?
> 
> Second the path is signaled using RSVP-TE with an Explicit 
> Route Object, and a T-Spec object.
> 
> The MS-PW RSVP-TE draft has failed to explain how PW specific 
> information would be propagated in an MPLS network in a 
> manner analogous to the first step above. Using OSPF-TE? 
> Maybe ISIS-TE? Maybe Marking MPLS tunnels for PW use only?
> 
> I propose that using the PCE architecture would be the only 
> reasonable method to perform PW TE across multiple domain and 
> multiple providers.
NH=> Ah....at last!  This is the 1st time I have seen it recognised that
we have a separate routing problem in this newly created PW layer
network.
> 
> Another major problem that is yet unresolved is the fact the 
> RSVP-TE signaling does not have the concept of a session. 
> (RSVP-TE refresh reduction is not a session).
NH=> Well, to be quite frank with you I don't really see a good
understanding of the need to separate 'call/session' control from
'connection/network-bearer' control....these are quite different issues
.....the ASON architecture tries to make sure this distinction is clear.
> 
> A session consists of initialization, and a well defined 
> message transport layer.  In LDP we have an LDP session setup 
> phase, and a TCP/IP session is used to transport messages 
> numbered in a sequence.
NH=> Yes I know....but your base problem is that you are failing to
grasp that the control-plane (and indeed management-plane) networks that
run IP should NOT be the same IP layer network that is carrying traffic.
You can't make this mistake in GMPLS as the co-cs mode forces the
control/management-plane OOB wrt the traffic data-plane network.  This
is THE fundamental problem with MPLS today.  All the symptoms you are
now dealing with stem from this base observation.

> The PW is then set up by sending 
> messages that are multiplexed within the TCP/IP transport 
> session - so the messages themselves do not require globally 
> unique addresses.
NH=> The PW layer network itself DOES need unique addresses...and they
have indeed been created in the SAII/TAII stuff.
> 
> RSVP, does not have the concept of a session, however 
> independent PW addressing can be achieved by using the the 
> SESSION object, and the SENDER_TEMPLATE. 
> The problem arises when a status message needs to be returned 
> by an intermediate S-PE in the MS-PW. The RSVP protocol is 
> only defined for IPV4 and IPV6, hence we cannot send a 
> message back to say that, for example, TX direction of S-PE 
> 102:10.0.0.1 failed for PW 102:10.0.0.45:401. (In LDP this is 
> done by using the PW status TLV in the LDP status notification).
> 
> How can this be done in RSVP-TE?  Maybe by creating the new address
> family for PW, and using RSVP notification mechanisms? 
NH=> This goes from bad to worse....another addressing family!

> Another
> possibility would be to use a RSVP notification mechanism to 
> just transport a message to the T-PE.
> 
> It is also unclear how the RSVP protocol would be used to set up PWs 
> in a network that has duplicate IP addresses.
> This is very common in service providers' internal networks, 
> not used to directly carry public IP traffic. Nodes are 
> generally addressed out of private IP space, and node IP 
> addresses will be commonly duplicated between providers (in 
> this case a status message from 10.0.0.1 would be effectively 
> anonymous, unless some other form of addressing is used). In 
> the LDP MS-PW proposal this is solved by allocating a unique 
> L2 PW address to the nodes acting as S-PE or T-PE.
NH=> The issue here is that the PW layer network has its own
addresses....these don't belong to the IP layer network (Note I can use
IP addresss structures to identify SDH VC4 trail term pts, but they have
nothing to do with an IP layer network).
> 
> None of these problems are addressed in 
> draft-raggarwa-rsvpte-pw-03.txt. Also a clear list of changes 
> required to RSVP would need to be included in the draft in 
> order for the WG to judge whether the protocol is 
> implementable and worthwhile.
> 
> GMPLS resolves some of these problems, however there are 2 
> major differences I can see:
> 1) GMPLS is used hop by hop in the PSN.
> 2) IP addressing of GMPLS nodes is reserved, and not used for 
> IP traffic
> - other then control traffic.
NH=> Luca....the main reason GMPLS is different (and right!) is that
there are always (at least) TWO networks in a co-cs layer network
system:  (i) the co-cs traffic data-plane and (ii) the cl-ps
control/management plane network...and never the twain shall meet (in
the traffic data-plane).  

But you won't understand WHY this is so unless you understand func arch,
and specifically the nature of labelling in the 3 networks modes.  We do
understand this stuff pretty well, and its been clear to us for a very
long time what problems were being created here.  All you are doing now
is slowly discovering them for yourself.
> 
> I believe that if there is a need for a GMPLS RSVP PW it 
> should be defined as a flavor of draft-kompella-ccc-02.txt.  
> This is a classical layer collapsing argument: we only need 
> to piggy back the PW information on the RSVP signaled LSP. In 
> this case there is a one to one mapping between PWs and RSVP-TE LSPs.
> 
> >From a service provider point of view there would be a few 
> advantages 
> >to
> this methodology: 
> 1) this traffic engineering technology is well established
> 2) only one protocol/session per PW is needed
> 3) OAM methods are all already well defined.
> 
> If a GMPLS PW that interfaces seamlessly with a GMPLS network 
> is needed then PWE3 and CCAMP should work on this together.
> 
> PWE3 has already defined the PW encapsulation, and it was 
> envisioned by myself and by the ADs at the time of the PWE3 WG 
> creation, that other WGs would also use these encapsulation 
> methods with other setup protocols that better fit their application.
NH=> The problem is not PW per se.....you ended up going here (symptom)
due to way MPLS is specified.  But if you don't recoignise the real
reason for the complexity/problems you are now seeing then how can you
ever properly fix it?  Some folks who have grasped these problems are
proposing the development of 'transport MPLS'.  I wait to see how
sucessful this will be.....but there are also alternatives now we can
consider.

regards, Neil
> 
> Luca
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3