ietf
[Top] [All Lists]

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

2011-07-13 16:52:48
Italo,

Comments inline.

Thanks,

John

Sent from my iPhone


-----Original Message-----
From: erminio(_dot_)ottone_69(_at_)libero(_dot_)it 
[mailto:erminio(_dot_)ottone_69(_at_)libero(_dot_)it]
Sent: Wednesday, July 13, 2011 2:04 PM
To: John E Drake; 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: 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(_at_)juniper(_dot_)net
Data: 13-lug-2011 22.46
A: 
"erminio(_dot_)ottone_69(_at_)libero(_dot_)it"<erminio(_dot_)ottone_69(_at_)libero(_dot_)it>,
"david.i.
allan(_at_)ericsson(_dot_)com"<david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com>,
 "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: 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(_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:   &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(_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

<Prev in Thread] Current Thread [Next in Thread>