David,
T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the
simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in
T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our interest
started with ITU-T's work in T-MPLS and not when IETF joined.
We value IETF's work, and in 2008, when the IETF rose doubts about future
interoperability between T-MPLS and MPLS/IP (and the "danger to the internet"),
even though all T-MPLS Recommendations were approved and the OAM one was ready
for approval, a decision was made to listen carefully to MPLS/IP's top experts'
input.
IETF's unilateral decision to select BFD was IMHO a surprise: being a primary
goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/expertise
or at least a compromise between the 2 SDOs. ITU-T's not just a boilerplate
stamper.
Hearing that "the decision was expressed in mpls-tp-analysis draft" was another
surprise: among the possible ways, the document showed, IMHO, 1731 as the
closest one to requirements.
We don't need a requirement to agree on reusing as most as possible MPLS and
PW: it's common sense. However, it can't distract us from primary goals.
"The issue is not code point, which is the trivial part. It is reuse of the
majority of the implementation. Again, pretty basic."
In other words, the problem is not backwards compatibility, (ergo the "danger
to the internet" problem never really existed) but maintaining particular
deployed platforms. If we had to convert cars into planes, we couldn't say "to
reuse the implementation, we can't add wings": they wouldn't fly.
I'm used to FW/HW development and i don't share your cost/simplicity view.
(Please check other LC responses on this particular point.) I know field
network support and think you'd change your opinion if you had to work on 24h
field network support.
I agree with you that other opinions exist, counting not only manufacturers but
also operators. On the operators that don't agree with you are certainly
clients of yours. It's none of my business that you view their opinions as
"grumblings", but that's far from describing the polls' results in the Feb2011
WG3 and SG15 plenaries, showing a minority sharing your view, and that,
although those not subscribing it tolerate its evolution, you don't theirs.
Operators and their clients are the ones that, at the end of the day, pay for
networks. From the above, it'll be IMHO impossible to understand if these
Recommendations don't take into account these "grumblers'" view, other than the
obsession of those insisting to sell swiss knifes to those who just want sharp
scalpels. Why don't we call that also "not constructive"?
"[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more
difficult to tell which is which.
[D:]That is because MPLS-TP is not a new techology, it is an addition to the
entire MPLS protocol suite."
Yes, i understand your view, David, but i'm sure you and i don't subscribe this
one:
"The creatures outside looked from pig to man, and from man to pig, and from
pig to man again; but already it was impossible to say which was which".
Hope this helps. My comrade cents,
Rui
-----Original Message-----
From: David Allan I [mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: erminio(_dot_)ottone_69(_at_)libero(_dot_)it; mpls(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: RE: [mpls] 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
Rui:
You wrote:
Reading something, keeping it on record, without effect in the draft and
"ignoring comments" have IMHO similar outcomes. As author of the draft you are
free to do it. These standards have a great impact
in our work, so i'm also free to write what i did.
Numerous comments did have effect on the draft and those that didn't were
either simply not actionable, were rhetorical or not constructive, and a few
had to be balanced against comments coming from the MPLS & BFD WGs. I would
translate "ingored" or "without effect" to "did not get one'e way". In the
standards process it happens.
My technical concerns regarding this draft were expressed...
...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe);
...in operators' meetings' that took place during ITU-T's Feb/2011 plenary
meeting;
I and the WG don't really have access to private grumblings.
Lots of other opinions were expressed as well, and they did not all agree with
you.
Some:
CC/CV
I don't understand the need for 2 types of packets: a single type allows CC;
mismatching identifiers in the same CC packets allow CV.
Besides adding complexity, we whether always activate both or potentiate
undetected mismerges.
OK, lets walk through this.
We want CV all the time so that any misconectivity can be detected, but on the
list it was expressed that the group did not want the overhead of processing
the source MEP TLV in every packet in order to achieve this. We could carry it
in every packet and have the receiver simply ignore most of them, but then that
would make the defect entry criteria compeltely random and the exit criteria
unreliable as well, not really a good design. Hence they are separated using
different ACH code points and the receiver is obliged to process every source
MEP TLV it receives. I hope this is clear.
(BTW: can't understand how we propose one ACH codepoint to CC, another for CV,
[counting other drafts, another for frame loss ...] but don't consider
assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T)
Because that puts you into two protocol ID demultiplexing steps per OAM PDU
recevied to determine the intended function. Hence COSTS MORE. That is pretty
basic...
Uni P2P / P2MP
I can't see how BFD will support unidir and hence P2MP other than...
...eliminating the session "state variable" (down, init, up), aiming just the
state variables we really need, bringing us to something similar to 1731,
eventually with other bits on the wire or...
...using IP to create the reverse way, which we cannot assume per
requirements;
Will we create a complete different tool for that?
(BFD's B="bidirectional")
I would not go so far as to say "similar to 1731", there is actually a lot of
difference under the hood. As for uni-directional BFD, that is a BFD WG problem
at the moment.
Provisioning list
This is an MPLS profile/subset (and i heard) achievable through a particular
configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that
profile/configuration. However, i keep seeing
references f.i. to IP encapsulations unexpected under TP's OAM.
I don't thus understand what the aim is: do we expect this in TP, are we
talking about MPLS in general?... The TP profile is never quite delimited.
Does chapter 4 contain ALL the configurable parameters list agreed to provide
in the comparison session?
It should. As for encapsulations, unless TP is in a complete island not
connected to anything (which as a network is rather useless) it will be
expected to interoperate with the rest of the MPLS architecture, and the stated
intention of tool development was that what resulted was applicable to the
broader MPLS architecture. Which means backwards compatiblity and procedures
for interoperation.
Backwards compatibility
This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment
plus coherence with SDH, OTN, as defended by ITU-T.
For reasons like the above, however, MPLS-TP BFD won't be backwards
compatible with previous BFD (even considering just CC/CV). They don't even
share the same codepoint.
The issue is not code point, which is the trivial part. It is reuse of the
majority of the implementation. Again, pretty basic.
Simplicity
Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: in
each flow, a standard defined nr of constant heartbeat signals (with standard
constant or provisioned period - no
auto/negotiated -) means OK. A standard defined number of misses means lost Rx
connection. An RDI, the only articulation between Rx and Tx flows, meaningful
in bidirectional applications, allows each
pear to identify Tx problems.
This OAM simplicity is the key for reliable fail finger pointing, performance
reports and protection. Also to allow scaling, more implementation
opportunities/manufacturers, which is valuable for
operators.
Well IMO there was not a lot of interest in T-MPLS until the IETF was going to
re-define it and make it compatible with IP/MPLS. So there was an industry wide
"design intent" implied here.
IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more
difficult to tell which is which.
That is because MPLS-TP is not a new techology, it is an addition to the entire
MPLS protocol suite.
Hope this helps
D
-----Original Message-----
From: David Allan I [mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: erminio(_dot_)ottone_69(_at_)libero(_dot_)it; Rui Costa;
ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: 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
-----Original Message-----
From: David Allan I [mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: erminio(_dot_)ottone_69(_at_)libero(_dot_)it; loa(_at_)pi(_dot_)nu; Rui
Costa
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: 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:
Two of the three document editors were present at SG15 plenary in February
where the comments originated. The revised meeting schedule resulted in a day
spent going through the document with the editors. IMO there were lots of
discussion and legitimate issues with the document identified and corrected so
it was a useful session. The liaison of same was in many ways *after the fact*.
Cheers
Dave
-----Original Message-----
From: erminio(_dot_)ottone_69(_at_)libero(_dot_)it
[mailto:erminio(_dot_)ottone_69(_at_)libero(_dot_)it]
Sent: quarta-feira, 6 de Julho de 2011 18:34
To: Rui Costa; ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: R: Re: [mpls] 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 way this draft has been developed is a bit strange.
The poll for its adoption as a WG document was halted by the MPLS WG chair
because "it is not possible to judge consensus":
http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html
The lack of consensus was motivated by serious technical concerns raised by
several transport experts during the poll.
Nevertheless the MPLS WG chair decided to adopt the draft as a WG document:
http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html
After several WG revisions and WG LCs, the technical issues have not been
resolved.
Several service providers regarded this draft as not meeting their
transport
networks' needs.
This is a true statement: the solution in this draft is useless for many MPLS-
TP deployments.
-----Original Message-----
From: erminio(_dot_)ottone_69(_at_)libero(_dot_)it
[mailto:erminio(_dot_)ottone_69(_at_)libero(_dot_)it]
Sent: quarta-feira, 6 de Julho de 2011 18:26
To: loa(_at_)pi(_dot_)nu; Rui Costa
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: R: Re: [mpls] 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
Version -04 of the document was published June 28th.
The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent
June 29th.
So when the WG LC to confirm the LC comment resolution has been launched?
The proto write-up says:
It has also passed a working roup call to verify that LC comments
were correctly with minor comments.
It also says:
The comments has been
carefully discussed between the authors and people making the
comments and
has been resolved.
But it seems that some comments have not been discussed with the authors of the
comments. When ITU-T Q10/15 has been involved in discussing its comments?
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: ietf(_at_)ietf(_dot_)org; IETF-Announce; mpls(_at_)ietf(_dot_)org
Subject: Re: [mpls] 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
All,
Since someone has commented about the process used for resolving
questions on
draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below.
The history of draft-ietf-mpls-tp-cc-cv-rdi working group review
process is:
On February 3rd 2011 the working group last call was issued
on version -03
This was copied to the the Ad Hoc Team List
and liaised to SG15 also on February 3rd
This working group last call ended om Feb 28
On Feb 28 we also received a liaison with comments from SG15
The authors compiled a list of all comments received as part the MPLS
working group last call; these comments - and the intended resolution -
is included in the meeting minutes from the Prague meeting:
http://www.ietf.org/proceedings/80/slides/mpls-9.pdf
During the IETF meeting in Prague, we agreed with the BFD working
group to do a separate working group last callfor the BFD working
group
The (BFD) working group last call was started on March 30th and ran
for 13 days. The last call ended on April 11th.
The authors have since worked hard to resolve comments, some
issue has been brought to the working group mailing list for
resolution.
Version -04 of the document was published June 28th.
The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent
June 29th.
The AD review resulted in a "New ID needed" due to mostly editorial
comments. Version -05 was published on June 29 and the IETF last call
started as soon as the new ID was avaialbe.
The current list of Last Call Comments resoltion is also avaiable at:
http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls
The list of issues that the authors kept very carefully, shows without
doubt
that no comments been ignored.
Loa
mpls wg document shepherd
-----Original Message-----
From: David Allan I [mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: RE: [mpls] 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 Rui:
The comments were not ignored, the resolution of the Q10 comments as well as
those collected from the MPLS WG was presented at the last IETF. My spreadsheet
from which that report was generated and has been augmented to include the BFD
WG comments is available at
http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls
So you know...
Dave
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: RE: [mpls] 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
IMHO and for the record:
ITU-T comments regarding this draft haven't been discussed with ITU-T but were
simply ignored. No LS describing these comments' resolution was sent.
Several service providers regarded this draft as not meeting their transport
networks' needs.
[The v03 draft was published in Feb and went to WG LC.
The v04 draft addressing WG LC comments was published on the 28th June (same
date as the proto write-up).
When was the WG LC launched, to verify LC comments resolution?]
Regards,
Rui
-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: [mpls] 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 IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile'
<draft-ietf-mpls-tp-cc-cv-rdi-05.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-07-14. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
Continuity Check, Proactive Connectivity Verification and Remote
Defect Indication functionalities are required for MPLS-TP OAM.
Continuity Check monitors the integrity of the continuity of the
label switched path for any loss of continuity defect. Connectivity
verification monitors the integrity of the routing of the label
switched path between sink and source for any connectivity issues.
Remote defect indication enables an End Point to report, to its
associated End Point, a fault or defect condition that it detects on
a pseudo wire, label switched path or Section.
This document specifies methods for proactive continuity check,
continuity verification, and remote defect indication for MPLS-TP
label switched paths, pseudo wires and Sections using Bidirectional
Forwarding Detection.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf