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

[Greg Mirsky <[e-mail]>]

Dear Erminio,
I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even
more narrow then of the document being discussed. The G.8113.1 addresses
only bi-directional co-routed LSP and has no model to handle bi-directional
associated LSP in independent mode. And unidirectional p2p and p2mp LSPs are
not addressed by the current revision of the G.8113.1.
Can all these out-of-scope constructs be used to conclude that G.8113.1 is
not capable to solve these issues? I don't think so. Solutions are not
readily available, that's all.

Regards,
Greg

On Wed, Jul 13, 2011 at 1:38 PM, [e-mail] <
[e-mail]> wrote:

> >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.
>
> The fact that the BFD WG has not defined a solution for unidirectional p2p
> and
> p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP
> nor
> does resolve the technical issue that have been raised.
>
> >----Messaggio originale----
> >Da: [e-mail]
> >Data: 8-lug-2011 18.13
> >A: "Rui Costa"<[e-mail]>, "Stewart Bryant"<[e-mail]
> >
> >Cc: "[e-mail]"<[e-mail]>,
> "mpls@ietf.
> org"<[e-mail]>, "[e-mail]"<[e-mail]>, "IETF-Announce"<ietf-
> [e-mail]>
> >Ogg: RE: [mpls] 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
> >
> >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.
> >
> >Meanwhile as an editor of the document, I'll take the liberty of
> responding
> to some of the points you raise...
> >
> >>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.
> >
> >>...in a comparison session that took place during that same ITU-T
> meeting.
> >
> >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:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 19:25
> >To: [e-mail]; Rui Costa; [e-mail]; IETF-Announce
> >Cc: [e-mail]
> >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:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 18:36
> >To: [e-mail]; [e-mail]; Rui Costa
> >Cc: [e-mail]; [e-mail]; 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: [e-mail] [mailto:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 18:34
> >To: Rui Costa; [e-mail]; IETF-Announce
> >Cc: [e-mail]
> >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: [e-mail] [mailto:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 18:26
> >To: [e-mail]; Rui Costa
> >Cc: [e-mail]; [e-mail]; 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:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 16:44
> >To: Rui Costa
> >Cc: [e-mail]; IETF-Announce; [e-mail]
> >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:[e-mail]]
> >Sent: quarta-feira, 6 de Julho de 2011 14:58
> >To: Rui Costa; [e-mail]; IETF-Announce
> >Cc: [e-mail]
> >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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Rui
> Costa
> >Sent: segunda-feira, 4 de Julho de 2011 23:03
> >To: [e-mail]; IETF-Announce
> >Cc: [e-mail]
> >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: [e-mail] [mailto:[e-mail]] On Behalf Of
> The
> IESG
> >Sent: quinta-feira, 30 de Junho de 2011 14:47
> >To: IETF-Announce
> >Cc: [e-mail]
> >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
> >[e-mail] mailing lists by 2011-07-14. Exceptionally, comments may be
> >sent to [e-mail] 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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> >_______________________________________________
> >Ietf mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ietf
> >
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>