Subject: [mpls-tp] [Fwd: (Forward to attendees) Meeting invitation: MPLS-TP weekly]

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Feb 2010 18:51:00 +0000

Malcolm will provide the exact agenda but the key goal is to discuss the 
pt-mp text in G.8110.1 and determine what IETF text needs to exist to 
support it.

- Stewart

**** You can forward this email invitation to attendees ****

Hello ,

Stewart Bryant invites you to attend this online meeting.

Topic: MPLS-TP weekly
Date: Tuesday, February 23, 2010
Time: 4:00 pm, GMT Time (London, GMT)
Meeting Number: 201 027 561
Meeting Password: mpls-tp

-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to 
https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&PW=NYTQ2YTRmMGY1&RT=MiMyMQ%3D%3D 
<https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&PW=NYTQ2YTRmMGY1&RT=MiMyMQ%3D%3D> 

2. Enter your name and email address.
3. Enter the meeting password: mpls-tp
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&PW=NYTQ2YTRmMGY1&ORT=MiMyMQ%3D%3D 
<https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&PW=NYTQ2YTRmMGY1&ORT=MiMyMQ%3D%3D> 

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San 
Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or 
Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked] <mailto:[email-masked]>
44-20-8824 8828

To add this meeting to your calendar program (for example Microsoft 
Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=m-bWQWy4MoX6kUwbXX5GVqxc2YfUrA4144c-F-T718Q=&RT=MiMyMQ%3D%3D 
<https://ciscosales.webex.com/ciscosales/j.php?ED=134724287&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=m-bWQWy4MoX6kUwbXX5GVqxc2YfUrA4144c-F-T718Q=&RT=MiMyMQ%3D%3D> 

The playback of UCF (Universal Communications Format) rich media files 
requires appropriate players. To view this type of rich media files in 
the meeting, please check whether you have the players installed on your 
computer by going to 
https://ciscosales.webex.com/ciscosales/systemdiagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

IMPORTANT NOTICE: This WebEx service includes a feature that allows 
audio and any documents and other materials exchanged or viewed during 
the session to be recorded. By joining this session, you automatically 
consent to such recordings. If you do not consent to the recording, do 
not join the session.

---

From: David Allan I <[email-masked]>
Date: Tue, 23 Feb 2010 16:40:33 -0500

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

---

From: <[email-masked]>
Date: Wed, 24 Feb 2010 08:54:15 -0000

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
> 
> 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Feb 2010 22:52:58 -0500

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

---

From: <[email-masked]>
Date: Thu, 25 Feb 2010 13:41:38 -0000

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 

> 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.
> 
> 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.
> 
> In message 
> <[email-masked]
> .systemhost.net>
> > 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:
> > 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 
> > We should also expand the problem statement below to take these 
> > factors into account:
> > 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.
> >  
> > 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.
> >  
> > > 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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 26 Feb 2010 00:14:16 -0500

> not grokking this anyway, I was merely pointing some of these.  Caveat

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

---

From: <[email-masked]>
Date: Fri, 26 Feb 2010 09:31:27 -0000

Curtis, you said:

CV=> MPLS-TP is a "profile".

I'm not sure one can attach any technical precision to the word
'profile'.  MPLS-TP re-uses certain DP/CP components from MPLS.  But the
imprecise term 'profile' is not important anyway.  What is important is
to understand that MPLS-TP will create a new type of MPLS layer network.
I often observe that this is not easy to grasp by folks who do not have
a background in the functional architecture modelling of networks, but a
simple way to grok what I mean here is to consider this question: 'what
access points can meaningfully be connected together?'.  The answer is
patently obvious when the technologies belong to different modes, eg try
connecting an SDH VC4 access point to a PDH E1 access points and see how
well that works.  However, the same can also be true when the
technologies belong to the same mode and, slightly more subtle, have
exactly the same traffic unit structure in the DP.  Try connecting an
RSVP-TP LSP access point to an LDP LSP access point. 

Are you starting to see what I mean here?

One of the interesting behaviours of MPLS is that it tries to keep a
common instance of routing whilst having lots of different signalling
protocols......this is also why it needs to be based on sublayering.
This model can be made to work quite well (at least under no
misconnectivity defects), but it is not what is required when one is
trying to provide a network builder transport service.  Some of the arch
problems of existing MPLS like LDP merging are obviously wrong and must
go, but others are more subtle....and the point I was making about the
need for transparency is one of the essential required behaviours of a
transport network.

The 'common instance of routing' case has a limited theatre of
applicability in practice of course....all the GMPLS work relates to
different layer networks (read as 'different instances of routing' if
you like).  And in MPLS this 'single instance of routing' myth is undone
the instant we consider what MS PWs are....these are a different layer
network to MPLS-TP and they need their own instance of routing which has
nothing to do with the MPLS-TP instance of routing. You should note that
all the AII stuff represents addressing of the access points of a MS PW
layer network....a technically amazingly bad decision made by folks who
clearly did not properly understand layering in networks and what I am
talking about here.  This is also why we can't re-use GMPLS signalling
for MS PWs and they have to have their own form of T-LDP signalling that
can handle these awful address structures. 

Of course. all this really ought to academic for MPLS-TP, as it should
not generate an unnecessary MS PW layer network at all if it is supposed
to be a transport network!

You also said:

CV=> > But lets not argue religion.

There is no (technology) religion in any of this.  I am merely going
over the technical facts that result from the underlying physics.  One
can try and understand it or not....but it's not 'my opinion' and/or
'religion', I have no choice in these things....just like I have no
choice in the mathematical fact that 2 + 2 = 4. If you really want to
grasp where I am coming from you would need to study G.800 as this
explains why the networking world looks like it does by going right back
to basics of Information and System Theory.  One can attempt to sum-up
what G.800 represents by saying 'it explains how we can carve-up a
time/freq/space resource dimension and label those resource partitions
in order to distinguish different instances of communication'.  There is
more to it than that of course, but that does capture the essence of it.

regards, Neil

> Sent: 26 February 2010 05:14
> Cc: [email-masked]; [email-masked]; [email-masked]
> <[email-masked]
> .systemhost.net>
> > 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.
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 26 Feb 2010 09:59:02 -0500

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"

Neil.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 01 Mar 2010 00:19:31 +0100

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:
> cannot apply what you say to any co-cs mode layer network controlled 
> If we do not provide true transparency in MPLS-TP then that's OK, but 
> 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 
> implications of not grokking this anyway, I was merely pointing some 

Neil.

Curtis

---

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,

Regards,
Maarten

-----Original Message-----

Curtis,

Cheers,
Ogor

-----Original Message-----

In message

Neil.

Curtis