Subject: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Jul 2011 22:26:35 +0200 (CEST)

>However this is a consequence of adapting an existing technology to a new 
application. I do not see any way around that. And the entire joint project was 
based on the premise of engineering re-use not greenfield design. That is what 
it said on the tin up front, and IMO why when the IETF started down this path 
packet transport transitioned from being a minority sport to mainstream, so it 
is a bit late to cry foul....

This is not what the IETF has committed to deliver to ITU-T and in fact slide 
44 postpones to the OAM design phase "decide whether LSP-Ping or BFD can or 
should be tweaked or not" and slide 46 reckons "many options including non IP 
BFD is an option encapsulation of Y.1731 PDU"

It seems to me after having read the draft and followed this very long thread 
that tweaking BFD is not the right approach to meet ITU-T requirements so it 
would be worth evaluating the other alternative considered viable by the JWT 
which is encapulating Y.1731 PDUs.

>----Messaggio originale----
>Da: [email-masked]
>Data: 6-lug-2011 20.24
>A: "[email-masked]"<[email-masked]>, 
"[email-masked]"<[email-masked]>, "[email-masked]"<[email-masked]>, 
"IETF-Announce"<[email-masked]>
>Cc: "[email-masked]"<[email-masked]>
>Ogg: RE: [mpls] R: Re: Last	Call:	&lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt&gt;	
(Proactive	Connectivity	Verification,	Continuity Check and Remote Defect 
indication	for	MPLS	Transport	Profile) to Proposed Standard
>
>Hi Erminio:
>
><snipped>
>>Several service providers regarded this draft as not meeting their 
>>transport networks' needs.	
>
>E> This is a true statement: the solution in this draft is useless for many 
MPLS- TP deployments.
>
>The two statements do not necessarily follow. 
>
>What we established during discussions at the SG15 plenary in February was 
that the issue some service providers had was that the IETF BFD solution 
exceeded their requirements in that there was additional functionality they did 
not see a need for, and that they considered any additional functionality 
parasitic.
>
>However this is a consequence of adapting an existing technology to a new 
application. I do not see any way around that. And the entire joint project was 
based on the premise of engineering re-use not greenfield design. That is what 
it said on the tin up front, and IMO why when the IETF started down this path 
packet transport transitioned from being a minority sport to mainstream, so it 
is a bit late to cry foul....
>My 2 cents
>Dave

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Jul 2011 13:46:27 -0700

Italo,

The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day.  I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15):

"The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures).  Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure.  These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP...

The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness."

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, July 13, 2011 1:27 PM
> To: [email-masked]; [email-masked]; [email-masked];
> IETF-Announce
> Cc: [email-masked]
> Subject: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-
> 05.txt> (Proactive Connectivity Verification, Continuity Check and
> Remote Defect indication for MPLS Transport Profile) to Proposed
> Standard
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls