Re: [mpls-tp] [PWE3] poll on draft-he-mpls-tp-csf-03.txt

[<[e-mail]>]

 Given I have seen no response to my important observation here I am reposting my comments:  In summary:

-	irrespective of how many folks say they 'support' this draft it is technically wrong and will lead to problems....this is just a fact, though I know from experience that technical accuracy and trying to warn of larger downstream problems that may not be immediately apparent often seem to count for little;

-	the draft is not even technically accurate of its primary architectural transparency violation (ie transporting a *client Y* signal fail indication by forcing the server Y/PW/MPLS layer network to 'understand' the client signal symbols) ....as I noted below in section 3.1 this is using a *server X* (of PW/MPLS/X) failure condition to be mapped into a *client Y* (of Y/PW/MPLS) failure.  Just how bad are folks prepared to make this functional coupling of different layer networks?

Aside=> When a client layer network is cl-ps there is no sensible way to map any server layer network connection failure (of a link connection in the client cl-ps layer topology) into a client layer failure indication.  If not obvious, then consider what indications are mapped into an IP v4 layer network from a SDH VC4 failure of a link connection in the IP layer network...the answer is none (and for jolly good technical reasons!).  

regards, Neil 
BT Design

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 18 November 2010 13:34
> To: [e-mail]
> Subject: Re: [mpls-tp] [PWE3] poll on draft-he-mpls-tp-csf-03.txt
> 
> 
>  I do not support this document as it is functionally 
> coupling a client and server layer network and this is 
> promulgating bad architectural practice.  If a client (or 
> indeed a server - as these roles are relative) does not have 
> the right OAM in its DP we must fix this problem in the 
> client (or server) and not add this functionality in a server 
> (or client).  Of course, this (need for client/server 
> functional independence) is a generic principle that applies 
> to other DP (and CP) functionality besides OAM.
> 
> Aside=> The draft is not even technically accurate, eg says 
> this is section 3.1:
> 
>    "Node B learns the failure between A and B either by 
> direct detection 
>    of signal fail (e.g. loss of signal) or by some fault indications 
>    between A and B (e.g. RDI, AIS/FDI)."
> 
> The 1st part of this sentence is dealing with a different 
> *server* (to the core MPLS/TP/PW partition server) for the 
> client...and the 2nd part of this sentence is only relevant 
> to a co-cs mode client and not general case co-ps ands cl-ps 
> clients.  Further, one should not be snooping client symbols 
> and trying to infer information from them...as they can 
> change for one thing!  This is a direct violation of 
> transparency and this simply should never happen in a pukka 
> transport network.  
> 
> regards,
> Neil Harrison
> BT Design
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Loa Andersson
> > Sent: 18 November 2010 11:56
> > To: [e-mail]; [e-mail]; [e-mail]; MPLS-TP 
> > ad hoc team
> > Subject: [PWE3] poll on draft-he-mpls-tp-csf-03.txt
> > 
> > all,
> > 
> > this is to start a two week poll on making
> > 
> > http://www.ietf.org/internet-drafts/draft-he-mpls-tp-csf-03.txt
> > 
> > a mpls working group document.
> > 
> > Please send comments support/not support to the mpls-tp 
> maililng list.
> > 
> > The poll ends Thursday Dec 2, 2010.
> > 
> > /Loa
> > -- 
> > 
> > 
> > Loa Andersson                         email: 
> > [e-mail]
> > Sr Strategy and Standards Manager            [e-mail]
> > Ericsson Inc                          phone: [phone]
> >                                               [phone] 
> > 13 _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> > 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>