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(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of
erminio(_dot_)ottone_69(_at_)libero(_dot_)it
Sent: Wednesday, July 13, 2011 1:27 PM
To: david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com;
RCosta(_at_)ptinovacao(_dot_)pt; ietf(_at_)ietf(_dot_)org;
IETF-Announce
Cc: mpls(_at_)ietf(_dot_)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(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com
Data: 6-lug-2011 20.24
A:
"erminio(_dot_)ottone_69(_at_)libero(_dot_)it"<erminio(_dot_)ottone_69(_at_)libero(_dot_)it>,
"RCosta(_at_)ptinovacao(_dot_)pt"<RCosta(_at_)ptinovacao(_dot_)pt>,
"ietf(_at_)ietf(_dot_)org"<ietf(_at_)ietf(_dot_)org>,
"IETF-Announce"<ietf-announce(_at_)ietf(_dot_)org>
Cc: "mpls(_at_)ietf(_dot_)org"<mpls(_at_)ietf(_dot_)org>
Ogg: RE: [mpls] 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
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf