RE: 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Italo,

Comments inline.

Thanks,

John

Sent from my iPhone


> -----Original Message-----
> From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it]
> Sent: Wednesday, July 13, 2011 2:04 PM
> To: John E Drake; david.i.allan@ericsson.com; RCosta@ptinovacao.pt;
> ietf@ietf.org; IETF-Announce
> Cc: mpls@ietf.org
> 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
> 
> The JWT report is aligned with my statement.

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

> 
> 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).

JD:  I'm not sure what your point is

> 
> 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.

JD:  Obviously we disagree

> 
> 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.

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?
 
> 
> >----Messaggio originale----
> >Da: jdrake@juniper.net
> >Data: 13-lug-2011 22.46
> >A: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>,
> "david.i.
> allan@ericsson.com"<david.i.allan@ericsson.com>, "RCosta@ptinovacao.pt"
> <RCosta@ptinovacao.pt>, "ietf@ietf.org"<ietf@ietf.org>, "IETF-
> Announce"<ietf-
> announce@ietf.org>
> >Cc: "mpls@ietf.org"<mpls@ietf.org>
> >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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
> Of
> >> erminio.ottone_69@libero.it
> >> Sent: Wednesday, July 13, 2011 1:27 PM
> >> To: david.i.allan@ericsson.com; RCosta@ptinovacao.pt; ietf@ietf.org;
> >> IETF-Announce
> >> Cc: mpls@ietf.org
> >> 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: david.i.allan@ericsson.com
> >> >Data: 6-lug-2011 20.24
> >> >A: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>,
> >> "RCosta@ptinovacao.pt"<RCosta@ptinovacao.pt>,
> >> "ietf@ietf.org"<ietf@ietf.org>,
> >> "IETF-Announce"<ietf-announce@ietf.org>
> >> >Cc: "mpls@ietf.org"<mpls@ietf.org>
> >> >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
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> 

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux