Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

From: "Drake, John E" <[email-masked]>
Date: Mon, 15 Dec 2008 10:26:13 -0800

If one really wanted to do this, the right way would be to use an IP router
John Drake
Boeing Satellite Systems
2260 East Imperial Highway MC W-S05-P208
El Segundo, CA 90245
[email-masked]
(412) 370-3108

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Mon Dec 15 10:18:12 2008
Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

Thanks Maarten,

Your major focus seems to be on defining all possible configuration
possibilities (which you then call 'transport entities') but you don't
seem that concerned about the more fundamental properties of forwarding
and transparency, and its implications on cost/complexity of the
networks that result....our focus has been on better understanding these
latter properties so that we can then better define the functional
specification of the networks we need, which includes OAM etc.

I fully stand by all I said in my earlier mail (which I don't consider
you have dealt with) and I note Deborah also shares some of my concerns
wrt the complexities that will ensue from trying to interwork different
network modes (esp given it's all rather unnecessary anyway).

I have spoken to Andy (Reid) about all this a few times today and I'm
hoping Andy can provide his views on these issues.

regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 15 December 2008 15:20
> To: Harrison,N,Neil,CXM R; [email-masked]
> Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network
> 
> Neil,
> 
> There is no misleading assertion in my writing. Our OAM is 
> used to monitor Transport Entities. In Ethernet the VLAN is a 
> Transport Entity and the
> Y.1731 Ethernet OAM is used to monitor this Ethernet 
> Transport Entity (i.e.
> VLAN).
> 
> There are three types of Transport Entities:
> 1) transport entities in which traffic units are forwarded 
> unconditionally (i.e. broadcast)
> 2) transport entities in which traffic units are by default 
> broadcast, but may have optional filtering applied
> 3) transport entities in which traffic units are forwarded on 
> the basis of configured forwarding rules; there is no default 
> braodcast rule in this case.
> 
> Examples of the first transport entities are the well known 
> p2p and p2mp connections in PDH, SDH, ATM, OTN.
> Examples of the second transport entities are the well known 
> p2p, p2mp, rmp and mp2mp VLANs in Ethernet. For the p2p and 
> p2mp VLANs there are no filtering rules registered; i.e. just 
> the default broadcast (flooding) is present.
> Example of the third transport entity is the IP VPN and the internet.
> 
> All those transport entity types are managed in the same 
> manner in a transport network, including their set up, 
> monitoring, protection and fault management.
> 
> I am summarizing those three transport entity types often by 
> their internal forwarding method as:
> 1) connection-oriented (CO) transport entity
> 2) connection-oriented plus connectionless (CO/CL) transport entity
> 3) connectionless (CL) transport entity.
> 
> OAM designed for a CO/CL transport entity is largerly the 
> same OAM as the OAM for a CO transport entity. 
> - The CO/CL transport entity OAM set includes essentially one 
> additional OAM PDU; i.e. the link trace OAM PDU which allows 
> to check the presence of a filtering rule in the Ethernet 
> Transport Entities (i.e. VLANs).
> - The other difference between the two OAM sets is the field 
> in the Loopback OAM PDUs in which the MIP and MEP identifier 
> is carried; in CO transport entity OAM this field is located 
> inside the LBM OAM PDU, in CO/CL transport entity OAM this 
> field is the DA field.
> 
> You will notice this equivalence when you compare Y.1731 with 
> the specifications in the latest draft version of G.8114 that 
> was not consented.
> 
> Interworking between p2p and p2mp Ethernet and MPLS-TP 
> transport entities is possible and should be supported in a 
> multi-technology packet transport network that includes 
> Ethernet VLAN based PTN domains and MPLS-TP based PTN 
> domains. This interworking capability creates hybrid Ethernet 
> VLAN/MPLS-TP p2p and p2mp channel layer connections. The 
> former T-MPLS OAM and linear protection switching 
> specifications were designed to support such hybrid channel 
> layer connections.
> 
> In MPLS-TP, this implies that e.g. a p2p Ethernet Service 
> VLAN will be continued as a p2p MPLS-TP PW. If the MPLS-TP 
> OAM and protection switching are look and feel alike with the 
> Ethernet OAM and protection switching, then the interworking 
> function (ETH/MT_IW) will be very simple and mainly has to 
> replace a VLAN Tag with a label stack entry header for 
> Ethernet services.
> When the MPLS-TP OAM and protection switching are not look 
> and feel alike, then the interworking function will be very 
> complex. Interworking for the case that a TDM service is 
> provided requires also the removal/insertion of DA/SA/TYPE 
> fields, again a simple task.
> 
> Regards,
> Maarten
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: maandag 15 december 2008 12:41
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network
> 
> There is a dangerous and misleading assertion in this...snipped to key
> point:
> 
> Maarten Vissers wrote 15 December 2008 10:36
> 
> > If the MPLS-TP functions and OAM mechanisms deviate too 
> much from the 
> > ETH functions and OAM mechanisms, then the equipment and 
> management of 
> > the MPLS-TP based PTN will be more complicated then 
> necessary. During 
> > the development of the T-MPLS specifications in ITU-T this 
> > co-existence has been fully recognized and resulted in strong 
> > alignment between the atomic functions and OAM of both 
> technologies to 
> > minimize equipment and network management complexities.
> > 
> > I hope that the MPLS-TP developments will also recognize this 
> > co-existence and result in strong alignment between the atomic 
> > functions and OAM of both technologies to minimize MPLS-TP 
> equipment 
> > and network management complexities.
>  
> 
> As a general observation it makes huge sense for the 
> functional components (and this is way more than just DP OAM) 
> of technologies that belong to the
> *same* network mode to migrate to the same optimised 
> functional components.
> Indeed, as an industry we have been very poor at achieving 
> this and each technology has largely had a new set of 
> components defined for it.  However, it makes no sense to try 
> and make all modes 'look alike'....they can't for a whole 
> raft of reasons, and it's why the 3 network modes are so 
> enduring (G.800 explains why this is technically, from 
> information theory considerations of how the labelling of 
> space/freq/time resource partitioning works).
> 
> So, to take a concrete example the OAM of a cl-ps mode 
> network should not try and be the same as the OAM of a co-cs 
> or co-ps mode network.
> See my recent to post to Sasha which contains one example to 
> support this observation.  And of course a cl-ps mode network 
> does not have connections (by definition) and this makes its 
> functional specification very different to a co-cs or co-ps 
> mode layer network....a signalling component is an obvious 
> difference.....and further in the co-cs mode this is forced 
> to run logically OOB in an adjunct layer network whereas this 
> is not forced (but is
> desirable) in the co-ps mode.
> 
> And just to be really clear wrt to my views on OAM here I am 
> NOT sure at all that ITU and even IEEE have done a great job 
> on OAM for Ethernet.....though IEEE did at least have the 
> very good sense to throw out AIS which is a completely 
> useless concept for a cl-ps mode layer network.  My personal 
> view is that the OAM that has been specified for Ethernet is 
> over-complex.....though if I had to home-in on one specific 
> aspect it would have to be nested TCM levels, I and most of 
> my collegaues here in BT don't think these are that useful 
> (go check how much of this old idea has been deployed in 
> operators networks, even where it could be argued it is most 
> relevant, ie long-holding co-cs mode networks).
> 
> As a minimum, folks really need to be clear just how such 
> nested OAM levels get dynamically configured across routing 
> changes (ie
> restoration/prot-sw) as only the end-points remain invariant 
> across such changes.  My view is that the OAM required needs 
> to be as simple/sparse as possible for the mode considered as 
> it needs to be considerably more reliable than the network it 
> is monitoring....so all unecessary config actions needs to be 
> removed and those that are left automated as much as possible 
> (eg activating/deactivating OAM in sync with signalling 
> connection set-up/tear-down for **co** mode networks).  I can 
> tell you for a fact that Operations folks will turn as much 
> unecessary OAM off as they can....it has a 
> processing/collection cost as well as a potential 
> unreliability factor.
> 
> Before closing I want to make one final and very important point here.
> There is an assumption made by some people that (i) 'peer 
> interworking'
> of different modes/technologies is a good idea and that (ii) 
> we need UNIs/NNIs in all cases.  Both these assumptions are 
> terribly flawed.
> 
> I can prove technically and very easily that:
> -	it is a complete nonsense to try and interwork technologies that
> belong to different network modes
> -	unless there is very close functional alignment across *all* DP
> and CP components (ie which is far more than OAM!) of 
> technologies that belong to the *same* network mode then peer 
> interworking will be a nightmare
> -	unless one is dealing with a top-of-stack layer network (and the
> critical observation here is that the layer network we are 
> dealing with has a suite of message/file/stream end-system 
> adaptation functions...not all have, including Ethernet and 
> MPLS/MPLS-TP note very carefully) then there is
> *no* technical requirement at all for NNIs.  
> 
> This latter point may not be immediately obvious to everyone, 
> but let me assure you it is a fact that can be easily proved.
> 
> So when we get around to specifying MPLS-TP let us please not 
> load it up with unecessary complexity, and let's try and 
> stick with the real operational requirements *and* try and 
> use the important findings from the work on unified modelling 
> in G.800 as our guide.
> 
> regards, Neil
> 
> 
> 
> 
_______________________________________________
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