Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Mar 2010 07:55:00 +0200

Maarten (and all),
I have added the L2VPN WG list since two of your comments deal with VPLS.

I disagree with two of your comments dealing with VPLS:

	VPLS technology is Ethernet VLAN technology

IMHO this incorrect:
Ethernet/VLAN (as technology) does not use "split horizon", and VPLS does not need any form of STP for loop elimination across a full mesh of PWs.

	PW label identifies the VPLS/VLAN instance

IMHO this is also incorrect/inaccurate:
Rx PW label identifies specific VPLS peer within the VPLS instance for MAC learning purposes.
As a consequence, a VSI with N peers requires N different Rx PW labels.

Modeling of VPLS (that includes 802.1-compliant bridge modules and VPLS Forwarders) is discussed in some detail in 
http://www.watersprings.org/pub/id/draft-ietf-l2vpn-vpls-bridge-interop-04.txt

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Monday, March 01, 2010 1:20 AM
To: 'Igor Bryskin'
Cc: [email-masked]
Subject: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

Igor,

If I would put MPLS-SP and MPLS-TP in a layer stack figure, I get the
following:

----------------------------------------------
|  MPLS-SP (RFC5654 transport service layer) |
|  includes LDP-PWs, BGP-PWs, Service-LSPs   |
|  VPLS, VPNs, etc                           |
----------------------------------------------
|  MPLS-TP (RFC5654 transport path layer)    |
|  includes edge-to-edge-LSPs, ..            |
----------------------------------------------
|  Transmission Media layer (includes        |
|  section and physical media layers)        |
----------------------------------------------

MPLS-SP can then be read as 'MPLS Service Path' layer, which supports
'service paths'.
MPLS-TP can then be read as 'MPLS Transport Path' layer, which supports
'transport paths'.

	Note that the VPLS technology is Ethernet VLAN technology and that
the
	PW label identifies the VPLS/VLAN instance.

PW, Service-LSP and VPLS instances (the 'service path signals') are all
carried by a 'MPLS transport path' (i.e. edge-to-edge LSP) as illustrated in
the figure below.

            |<---- Pseudowire, Service LSP and VPLS/VLAN ---->|
            |      encapsulated packet "service paths"        |
            |                                                 |
            |                                                 |
            |   |<---edge-to-edge LSP1--->|    edge-to-edge   |
        AC  |   |    "transport path"     |    |<--LSP2-->|   |  AC
         |  V   V                         V    V          V   V  |
         | +----+              +-----+    +----+          +----+ |
   +---+ | |TPE1|===============\ P /=====|SPE1|==========|TPE2| | +---+
   |   |---|......PW1-Seg1.... |     | ......X...PW1-Seg2......|---|   |
   |CE | | |    |              |     |    |    |          |    | | |CE |
   |11 |---|......PW2-Seg1.... |     | ......X...PW2-Seg2......|---|21 |
   +---+ | |    |              |     |    |    |          |    | | +---+
   |   |---|.....SLSP1-Seg1... | \ / | ......X..SLSP1-Seg2.....|---|   |
   |CE | | |    |              |  X  |    |    |          |    | | |CE |
   |12 |---|.....SLSP2-Seg1... | / \ | ......X..SLSP2-Seg2.....|---|22 |
   +---+ | |    |              |     |    |    |          |    | | +---+
   |   |---|......VPLS1-Seg1.. |     | ......X..VPLS1-Seg2.....|---|   |
   |CE | | |    |              |     |    |    |          |    | | |CE |
   |13 |---|......VPLS2-Seg1.. |     | ......X..VPLS2-Seg2.....|---|23 |
   +---+ | |    |===============/   \=====|    |==========|    | | +---+
           +----+     ^        +-----+    +----+     ^    +----+   
                      |                              |             
                   TE LSP                         TE LSP           

             Figure - MPLS-TP edge-to-edge LSP transporting PW, Service-LSP
               and VPLS/VLAN 'service paths' (= RFC5654 transport service
		               layer transport path) signals

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: vrijdag 26 februari 2010 15:59
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] PHBs and "ordered aggregates"

Curtis,

I believe that one of our serious problems is that we keep calling MPLS-TP
MPLS transport profile, while in fact this is IMO nothing but MPLS traffic
engineered (controlled by GMPLS or NMS) transport layer providing services
to various clients and one of them is MPLS service layer (some people call
it MPLS-SP) that includes LDP-PWs, BGP-PWs, VPLS, VPNs, etc.). The two
layers (MPLS-TP and MPLS-SP) share the same data plane, but from the CP,
say, point of view they have quite literally nothing in common.

Cheers,
Ogor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: Friday, February 26, 2010 12:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] PHBs and "ordered aggregates"

In message
<[email-masked]
t>
[email-masked] writes:
>  
> Hi Curtis....wow, long time no hear.  I know what you are saying here 
> but this is not what a transport network is supposed to be doing.  You 
> cannot apply what you say to any co-cs mode layer network controlled 
> by GMPLS...just a fact of the physics.
>  
> If we do not provide true transparency in MPLS-TP then that's OK, but 
> it also means that MPLS-TP should really stop claiming it is a 
> transport network.  In fact, I would argue that the mere fact MS PWs 
> still appear in MPLS-TP alone is a fairly obvious indication that it 
> has failed in its transport network aspirations.
>  
> This sort of technical accuracy seems not to matter any longer from 
> what I am observing....so be it, but there are also practical 
> implications of not grokking this anyway, I was merely pointing some 
> of these.  Caveat emptor now.
>  
> regards, Neil

Neil.

MPLS-TP is a "profile".  A given provider can in effect enable or
disable aspects of the profile if they prefer to do so for business
reasons rather than for sake of some notion of transport purity.

But lets not argue religion.

The specs have a lot of SHOULD so that providers still have choices.

Curtis

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: 25 February 2010 03:53
> > To: Harrison,N,Neil,DKQ7 R
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] PHBs and "ordered aggregates" 
> > 
> > 
> > Hi Neil.
> > 
> > AF service has more than one PHB per OA.  That is on purpose. 
> >  The rule is one PSC per OA, not one PHB.  The color marking 
> > affect only the drop preference.
> > 
> > All other defined diffserv services have one PHB per OA.
> > 
> > If you don't like AF, don't use it.
> > 
> > Re: "the server layer resources must not be overbooked".  In 
> > the event of a fault, a disconnected IP network is worse than 
> > a mildly congested one, particularly if diffserv is used and 
> > the only thing slowed down is the BE service.  To do that, 
> > you need to allow overbooking.  Hint:
> > use MPLS holding-pri with the Russian Dolls model and only 
> > overbook the priority containing BE.
> > 
> > MPLS doesn't need any changes to allow this.
> > 
> > Curtis
> > 
> > 
> > In message 
> > <[email-masked]
> > .systemhost.net>
> > [email-masked] writes:
> > >  
> > > Hi Dave,
> > >  
> > > The deeper (G.800) architectural point you are getting at 
> > here is one 
> > > of transparency...which is THE key service that a server layer 
> > > (transport) network needs to deliver to its clients.  What 
> > this means 
> > > practically is
> > > this:
> > > -	the server network must be based on single source connection
> > > constructs
> > > -	the server layer resources must not be overbooked 
> > > -	the server network must not try and impart any meaning to client
> > > layer symbols and for sure not change them.....in essence no 
> > > snooping/DPI
> > > -	a (parent) connection must not re-order its (child) traffic
> > > units...and the sting in the tail from this observation is that a 
> > > connection must only have a single traffic class....QoS 
> > class if you 
> > > like, but noting that urgency and importance are orthogonal 
> > metrics of 
> > > a message/file/stream client application that is external 
> > to the TOS 
> > > layer network, and some lower server layer network must not try and 
> > > infer dynamic meaning of these metrics from observing 
> > client traffic 
> > > unit flows.  This point becomes very important in practical network 
> > > interconnects that occur in a BOS network layer network.
> > >  
> > > We should also expand the problem statement below to take these 
> > > factors into account:
> > > -	Net Perf metrics/objectives only relate to the available state.
> > > -	Net Perf metrics/objectives apply independently to each
> > > direction of a bidirectional connection 
> > > -	For all bidirectional connections if one direction enters the
> > > unavailable state then the Net Perf SLA process must be suspended in
> > > *both* directions.
> > >  
> > > The above is important in order to prevent Net Perf SLAs being 
> > > distorted by outage events.....though I would caution, from 
> > practical 
> > > measurements I did in transport networks when 
> > mathematically modelling 
> > > error/outage events, that a 10 second entry criteria for the 
> > > unavailable state is too long and short-break events (ie 
> > outage events 
> > > that terminate before 10s is reached) will also distort Net 
> > Perf objectives.
> > >  
> > > The above creates some rather serious challenges wrt to 
> > synchronising 
> > > the start/stopping of Net Perf processes if one wants a 
> > good degree of 
> > > accuracy.....which is not trivial even at trail termination points, 
> > > let alone in any nested TCM sublayers, noting that on failures we 
> > > often need to re-route connections and so only the trail 
> > termination 
> > > locations will remain invariant across such restoration event.
> > >  
> > > BTW - It should also be rather obvious from the above that 
> > if one has 
> > > multiple QoS (sic) classes in a connection then the handling of 
> > > entry/exit of unavailable events will become practically 
> > intractable 
> > > anyway, even at true trail termination points.
> > >  
> > > regards, Neil
> > >  
> > >  
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of David Allan I
> > > > Sent: 23 February 2010 21:41
> > > > To: [email-masked]
> > > > Subject: [mpls-tp] PHBs and "ordered aggregates"
> > > > 
> > > > Hi TPers
> > > > 
> > > > A question relating to the LM transaction.
> > > > 
> > > > Ideally an LM transaction can measure an ordered 
> > aggregate as the LM 
> > > > transactions benefit from the ordering guarantees and the counts 
> > > > therefore reflect packets in flight at the time the LM is issued.
> > > > 
> > > > The problem is having the OA correspond to something 
> > useful that can 
> > > > be identified in the LM such that it shares queing 
> > discipline with 
> > > > the OA (vs. simply microflow guarantees). A read of 3260 suggests 
> > > > that a 1:1 correspondence between OA and PHB or PHB class 
> > does not 
> > > > necessarily exist but that the deltas in ordering 
> > guarantees seems 
> > > > to be at least partially on the basis (my inference) of arbitrary 
> > > > ECMP next hop selection criteria.
> > > > 
> > > > It strikes me that for TP we need a stake in the ground 
> > that a PHB 
> > > > on a transport path is an ordered aggregate, or we post a huge 
> > > > health warning on LM that "actual mileage may vary"....
> > > > 
> > > > WDYT?
> > > > Dave
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > 
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp