Re: [mpls-tp] [mpls] Poll for draft-gray-mpls-tp-nm-req-03 to become an mpls wgdocument

[<[e-mail]>]

Hi Eric,

This is a good document and I support it.  I have few minor comments for
you and your fellow authors to consider please:

1	Section 5.1 says:
 		". Supervision of looping check functions used to detect
loops 
            in the data-plane forwarding path (which result in non-
            delivery of traffic, wasting of forwarding resources and 
            unintended self-replication of traffic);"

Is this meant to imply the reception of too high a number of correct CV
messages in some period T?


2	Ibid: 

          	". Supervision of Alarms based on native OAM, e.g., AIS
(Alarm 
            Indication Signal) and FDI (Forward Defect Indication)"

AIS (all 1s) is required for time-dim co-cs clients but FDI is a
'possible' requirement for co-ps clients......there should be no such
indication sent to cl-ps clients.  Note that IEEE have removed the
AIS/FDI requirement for Ethernet in .1ag, even though ITU have left it
in Y.1731...IMO IEEE have made the right choice here.  The reason I say
'possible' for co-ps clients is that it takes effort to generate FDI in
the co-ps mode (unlike all 1s for the co-cs mode which is a default
condition on failure) and it also means the server layer trail
termination point needs to 'remember' what clients it was serving before
the defect.  But if clients have their own CV flows then this is a much
better approach (Note - co-cs server layer AIS has been used in the past
almost as an excuse not to have a CV flows in a client co-ps layer
network).  I think the case for alarm storms we sometimes hear (and I
have been guilty of this one in the past) is a little over done.

BTW 1 - Do not confuse FDI and BDI.  BDI is much more important and,
most crucially, is at the same layer as the CV OAM flow and the defect
to allow single ended defect monitoring of bidirectionally symmetric p2p
LSPs.  FDI is something injected into the client above the level of the
defect.

BTW 2 - If we keep nested sublayers natively in MPLS-TP (ie S bit issue)
then one needs to be clear about FDI in this case (ie of higher LSP
sublayers) vs real different layer clients.  For those real higher
clients that need AIS/FDI then we will need to generate it, but for
nested LSP sublayers I am not so sure.  On balance I would not do this.

No doubt Maarten will disagree with me about the importance of FDI ;-)


3	And as a general observation on CV flows.  In a co-ps mode layer
network based on label swapping one requires CV flows on all LSP
connections irrespective of importance...else one can't catch cases of
important traffic from one LSP getting unintendedly replicated and
merged into a non-important LSP.  But the CV rate used should be the
same in the whole network.  If it isn't one can get cases of alarm
cycling.  For example a 1/min LSP_A CV flow misconnected into a 1/s
LSP_B CV flow will give rise to (i) mismerge detected at LSP_B trail
termination point at t=X and alarm raised with BDI sent backwards (and
possibly FDI sent forward if used), (ii) at t=X+3 the defect appears to
clear, so alarm, BDI (and any FDI) stopped on LSP_B, (iii) we then get
57 secs of apparent defect-free behaviour but at t=X+60 the alarm cycle
starts again on LSP_B.


4	In section 5.3.2 it says:

	  "Note: An MPLS-TP NE supporting the inter-working of one or
more 
        networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with 
        MPLS-TP needs to translate an MPLS-TP fault into an existing 
        transport technology failure condition for reporting to the 
        management system. 

        See RFC 4377 [2] for more description."

Two points here:

-	Firstly, the 'Note' should strictly refer to a client/server
case and not 'interworking'.  There should be no concept of
peer-interworking of non top-of-stack layer networks, and especially so
if they are different modes.  If we do not clamp down on this it will
lead to unnecessary and wasted effort/cost.

Aside=> MPLS-TP will create a different layer network to MPLS.  This is
just a fact, and nothing to get upset/alarmed about (MPLS is not even
singular as a layer network anyway)....but it is important to understand
*why* this is so....because if we don't, the door will be opened to
peer-interworking with other technologies.

The simple acid test is this:  Does *this* layer network support
message/file/stream application adaptation functions directly?  If the
answer is no then there is no need to either (i) partition this layer
network and create UNI/E-NNIs (are you reading this Andy Malis, because
your MPLSF ICI stuff breaks this rule...but you are not alone, MEF and
OIF are trying to commit the same mistake) or (ii) (even worse) try and
peer-interwork this layer network technology with some other layer
network technology.  Only networks that support message/file/stream
application adaptation functions have a need to create UNIs/E-NNIs and
have horizontal same layer/technology peering relationships between
different parties...like IP in the public Internet for example, as that
is most definitely a top-of-stack network.  The PSTN is the same.  But
none of this applies to any other mode/technology.

-	Secondly, RFC4437 is not bad but it tries to accommodate the
arch violations found in some forms of MPLS that have to be removed in
MPLS-TP, eg LDP merging.  So whilst some of this is relevant, not all of
it is.


5	In section 6.5 we find:

	  "The MPLS-TP NE MUST support the capability to configure the
OAM 
        entities/functions as part of LSP setup, including bidirectional

        point-to-point connections, associated uni-directional point-to-
        point connections, and uni-directional point-to-multipoint 
        connections."

This is correct.  But the key point is that both activation *and
deactivation* of defect detecting/handling OAM needs to be synchronised
to the set-up *and tear-down* of the LSPs.

Note - I am not considering nested TCM OAM sublayers here.  I am only
considering the OAM for the important trail termination points of the
LSP.  If nested TCM OAM sublayering is to be considered then it must be
made clear how the TCM sublayers are activated/deactivated and how any
PM measurements in such are synchronised across LSP failure/restore
events.  Never seen how to do this yet.

regards, Neil

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Loa Andersson
> Sent: 06 February 2009 15:18
> To: Eric Gray
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: [mpls] Poll for draft-gray-mpls-tp-nm-req-03 to 
> become an mpls wgdocument
> 
> All,
> 
> as you can see below the authors of 
> draft-gray-mpls-tp-nm-req-03 has request that we accept the 
> draft as a working group draft.
> 
> This is to initiate a two week poll if we want to accept it 
> as a working group document.
> 
> Please send your comments to the mpls-tp list.
> 
> /Loa
> 
> Eric Gray wrote:
> > A new version of this draft has been posted, based on comments 
> > received and an editing session last month in Ipswich, UK.
> > 
> > As discussed at the Ipswich meeting, we would now like to 
> ask the WG 
> > Chairs, and the WG, to adopt this version as a working 
> group docment.
> > 
> > Thanks in advance...
> > 
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:[e-mail]]
> > Sent: Friday, February 06, 2009 8:51 AM
> > To: Eric Gray
> > Cc: Scott Mansfield; [e-mail]
> > Subject: New Version Notification for draft-gray-mpls-tp-nm-req-03
> > Importance: High
> > 
> > 
> > A new version of I-D, draft-gray-mpls-tp-nm-req-03.txt has been 
> > successfuly submitted by Eric Gray and posted to the IETF 
> repository.
> > 
> > Filename:	 draft-gray-mpls-tp-nm-req
> > Revision:	 03
> > Title:		 MPLS TP Network Management Requirements
> > Creation_date:	 2009-02-04
> > WG ID:		 Independent Submission
> > Number_of_pages: 20
> > 
> > Abstract:
> > This document specifies the requirements necessary to manage the
> > 
> >   elements and networks that support an MPLS Transport Profile
> > 
> >   (MPLS-TP). This document is a product of a joint International
> > 
> >   Telecommunications Union - Telecommunications Standardization
> > 
> >   Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
> > 
> >   to include a MPLS Transport Profile within the IETF MPLS
> > 
> >   architecture. The requirements are driven by the management
> > 
> >   functionality needs defined by ITU-T for packet transport
> > 
> >   networks. 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >   Gray, et al
> > 
> > 
> > 
> >   Expires August, 2009
> > 
> > 
> > 
> >   [page 1]
> >  
> > 
> > 
> > 
> > 
> >   Internet-Draft
> > 
> > 
> > MPLS-TP NM Requirements
> > 
> >  February, 2009
> >  
> > 
> > 
> > 
> > The IETF Secretariat.
> > 
> > 
> > _______________________________________________
> > Mpls-interop mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-interop
> 
> -- 
> 
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  [phone]
> 
>                                        email:  
> [e-mail]
>                                                
> [e-mail]
>                                                [e-mail]
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>