Subject: [mpls] R: RE: 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 23:04:13 +0200 (CEST)

The JWT report is aligned with my statement.

The decision at IETF75 has been taken by the MPLS WG after the JWT and has 
never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he 
later removed his name because the other editors of the OAM Analysis draft were 
not considering his input to the document).

The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was 
completely different (and technically much superior) than the one described by 
this draft.

Accepting a solution that meets the requirements does not mean signing a blank 
cheque that whichever changes is done is acceptable regarless whether it meets 
or not the requirements.

>----Messaggio originale----
>Da: [email-masked]
>Data: 13-lug-2011 22.46
>A: "[email-masked]"<[email-masked]>, "david.i.
[email-masked]"<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"<[email-masked]>, "IETF-Announce"<ietf-
[email-masked]>
>Cc: "[email-masked]"<[email-masked]>
>Ogg: RE: [mpls] R: RE: 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
>
>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
>> 
>> >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
>> >
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Jul 2011 14:50:59 -0700

Italo,

Comments inline.

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 13, 2011 2:04 PM
> To: John E Drake; [email-masked]; [email-masked];
> [email-masked]; IETF-Announce
> Cc: [email-masked]
> Subject: R: RE: [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
> 

JD:  As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues

> not considering his input to the document).

JD:  I'm not sure what your point is

> completely different (and technically much superior) than the one

JD:  Obviously we disagree

> cheque that whichever changes is done is acceptable regarless whether

JD:  The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon?
 
> "david.i.
> >The design team report
> (http://www.ietf.org/proceedings/75/slides/mpls-

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 14 Jul 2011 13:14:54 -0700

To the extent that this particular debate (that of the nature scope and success or failure of the liaison effort) has been going on for some time:

* it's not going to be resolved.
* rehashing the history of how we came to this point it advances what agenda?

It would seems timely in the IETF last call to focus the line of criticism on the merits or lack thereof of the draft as it stands, not on how we arrived here.

joel