Re: [mpls-tp] MEG

I believe your concerns are well-founded Nitin.  We have looked closely
at TCM and in most technologies (any of the 3 modes) it is an
artificially imposed form of horizontal layer
peer-partitioning...however it is 'sold' as hierarchy but it is most
definitely not client/server hierarchy, but an arbitrarily imposed
partitioning of a single layer network.  This is one reason why we in BT
have major concerns about its practical viability, eg only true
end-points (ie network access points) in this single layer network
remain invariant over any failure/recovery events.

MPLS however does create a form of true hierarchy, which is quite
different to how TCM has been applied in other technologies as I noted
above.  Indeed it would be true/real client/server hierarchy *iff* each
LSP has its own functionally independent DP/CP/MP.  However, in the
original arch specification of MPLS it was assumed we could allow nested
LSPs to be sublayers within the same CP/MP domain, ie a "single CP" over
all nested LSPs, and this is what the S bit was to supposed to
represent.  Moreover, it is also why trying to create true client/server
isolation between LSPs belonging to *different MPLS network instances*
(ie MPLS network belonging to party A carried transparently over the
MPLS network belonging to party B) required the forced insertion of an
'ethernet PW functional breakwater' (to separate all 3 DP/CP/MP
functional planes in the 2 MPLS layer networks).....see the draft
Stewart/I kicked-off over a year ago on this
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-04.tx
t

regards, Neil

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org 
> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Nitin Bahadur
> Sent: 16 July 2009 20:32
> To: 'Maarten Vissers'; 'Sprecher, Nurit (NSN -IL/Hod 
> HaSharon)'; mpls-tp@ietf.org
> Subject: Re: [mpls-tp] MEG - who, what and how
> 
> Hi Maarten,
> 
>    Thanks for the clarifications. See inline below.
> 
> > The transport entity, ME, MEG and MEG Level are abstract 
> constructs that
> > we
> > have defined to describe a specific application/behaviour.
> 
> ME & MEG, I understand as abstract concepts.
> 
> > - MPLS-TP Section, LSP and MS-PW: supported are infinite 
> number of MEG
> > levels due to use of label stacking as MEG level encoding method.
>  
> > Note that there is a major difference between the MEG Level 
> as abstract
> > construct and the "MEG Level (MEL)" field in which for Ethernet the
> > abstract
> > MEG Level is encoded. 
> 
> > The MEG Level as abstract construct is necessary in
> > MPLS-TP OAM,
> 
> I am not 100% convinced...probably my lack of knowledge. See 
> more below on this.
> 
> > the MEL field in a MPLS-TP packet is not necessary (but may
> > be
> > present for PDU commonality and is then ignored in the receiver).
> 
> Ok.
>  
> > The consequence of choosing the label stacking method to 
> identify MEG
> > levels
> > in MPLS-TP is that the label stack entry header is now 
> associated with two
> > functions as well:
> > 1) identification of client, transport of QoS information, 
> loop mitigation
> > and
> > 2) identification of OAM MEG level.
> 
> Again, I'm not clear why you want to use label stacking to 
> identify MEG level. I'm not clear as to why you want to 
> identify the MEG level in the first place.
> 
> In case of MPLS-TP, each LSP by itself will have it's own 
> OAM. Each LSP and end-to-end entity cares about it's own OAM. 
> Whether that LSP goes over 2 other layers of LSPs (multiple 
> levels of network elements) should not be a concern for that 
> LSP. By identifying a MEG level for LSPs, you are introducing 
> the concept of one layer knowing about the implicit presence 
> of another layer. 
> 
> When you are performing OAM over a particular layer, the OAM 
> PDU should have sufficient information for an end-point to 
> identify the entity on which OAM is being performed on. If 
> you say that MEG level is one way to identify the 
> layer/entity, then MEG is a *solution* and not a *requirement*. 
> 
> If MEG level serves some other purpose, then could you help 
> clarifying that.
> 
> Thanks
> Nitin
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 