Subject: [mpls] FW: 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

From: Eric Gray <[email-masked]>
Date: Wed, 27 Jul 2011 12:32:07 -0400

Forwarding in plain text...

________________________________

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 10:57 PM
To: [email-masked]
Cc: David Allan I; Rui Costa; Stewart Bryant; [email-masked]; [email-masked]; 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

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, [email-masked] <[email-masked]> 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: [email-masked]

        >Data: 8-lug-2011 18.13
        >A: "Rui Costa"<[email-masked]>, "Stewart Bryant"<[email-masked]>
        >Cc: "[email-masked]"<[email-masked]>, "mpls@ietf.
        org"<[email-masked]>, "[email-masked]"<[email-masked]>, "IETF-Announce"<ietf-
        [email-masked]>
        >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:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 19:25

        >To: [email-masked]; Rui Costa; [email-masked]; IETF-Announce
        >Cc: [email-masked]

        >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:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 18:36

        >To: [email-masked]; [email-masked]; Rui Costa
        >Cc: [email-masked]; [email-masked]; 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: [email-masked] [mailto:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 18:34

        >To: Rui Costa; [email-masked]; IETF-Announce
        >Cc: [email-masked]

        >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: [email-masked] [mailto:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 18:26

        >To: [email-masked]; Rui Costa
        >Cc: [email-masked]; [email-masked]; 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:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 16:44
        >To: Rui Costa

        >Cc: [email-masked]; IETF-Announce; [email-masked]

        >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 <http://www.pi.nu/%7Eloa/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:[email-masked]]
        >Sent: quarta-feira, 6 de Julho de 2011 14:58

        >To: Rui Costa; [email-masked]; IETF-Announce
        >Cc: [email-masked]

        >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 <http://www.pi.nu/%7Eloa/cc-cv-rdi-Last-Call-Comments> .
        xls

        >So you know...
        >Dave
        >
        >
        >-----Original Message-----

        >From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui
        Costa
        >Sent: segunda-feira, 4 de Julho de 2011 23:03

        >To: [email-masked]; IETF-Announce
        >Cc: [email-masked]
        >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: [email-masked] [mailto:[email-masked]] On Behalf Of The
        IESG
        >Sent: quinta-feira, 30 de Junho de 2011 14:47
        >To: IETF-Announce
        >Cc: [email-masked]

        >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
        >[email-masked] mailing lists by 2011-07-14. Exceptionally, comments may be
        >sent to [email-masked] 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
        >[email-masked]
        >https://www.ietf.org/mailman/listinfo/mpls
        >
        >

        >_______________________________________________
        >Ietf mailing list
        >[email-masked]
        >https://www.ietf.org/mailman/listinfo/ietf

        _______________________________________________
        mpls mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/mpls

---

From: Maarten vissers <[email-masked]>
Date: Wed, 27 Jul 2011 19:49:16 +0000

G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, p2mp unidir connections. 

The p2p bidir connection can be co-routed, and then it is possible to perform e.g. loopback at intermediate nodes. 

The p2p bidir connection can be associated, and then a loopback at an intermediate node will not be possible. But the end-to-end monitoring is still performed without problems. 

Note that a co-routed bidir 1+1 protected connection can select it's A-to-Z traffic from working and its Z-to-A traffic from protection; this effectively creates an associated bidir connection in which e2e monitoring is supported but loopbacks at intermediate nodes are not successful.

Regards,
Maarten

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eric Gray
> Sent: 27 July 2011 18:32
> To: [email-masked]
> Subject: [mpls] FW: 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
> 
> 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
> 
> 
> 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
> 
> 
>         >Cc:
> "[email-masked]"<[email-masked]>, "mpls@ietf.
>         >  http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls
> <http://www.pi.nu/%7Eloa/cc-cv-rdi-Last-Call-Comments.xls>
>         >
>         WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-
> Last-Call-Comments <http://www.pi.nu/%7Eloa/cc-cv-rdi-Last-Call-
> Comments> .
>         xls
>         >
> 
>         >So you know...
>         >Dave
>         >
>         >

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 27 Jul 2011 15:54:11 -0400

Dear Maarten,
the question was raised in regard to CC/CV, a.k.a. CCM, functionality. I apologize that I didn't state that explicitly and left it as implied context of the discussion. I don't question G.8113.1 capabilities you've listed but only compare with corresponding CCM addressed in CC-CV-RDI.

Regards,
Greg
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Maarten vissers [[email-masked]]
Sent: Wednesday, July 27, 2011 3:49 PM
To: Eric Gray; [email-masked]
Subject: Re: [mpls] FW: 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

Regards,
Maarten

---

From: Maarten vissers <[email-masked]>
Date: Wed, 27 Jul 2011 20:16:42 +0000

Dear Greg,

G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in 
- co-routed bidir p2p, 
- associated bidir p2p, 
- unidir p2p and 
- unidir p2mp 
PW, LSP, SPME and section connections.

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

Solution for CCM is already available in G.8113.1. 
I.e. G.8113.1 already resolved these issues as such.

Regards,
Maarten

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: 27 July 2011 21:54
> To: Maarten vissers; [email-masked]
> Subject: RE: [mpls] FW: R: RE: Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and
> the question was raised in regard to CC/CV, a.k.a. CCM, functionality.
> I apologize that I didn't state that explicitly and left it as implied
> context of the discussion. I don't question G.8113.1 capabilities
> you've listed but only compare with corresponding CCM addressed in CC-
> CV-RDI.
> 
> Regards,
> Greg
> From: [email-masked] [[email-masked]] On Behalf Of
> Maarten vissers [[email-masked]]
> Subject: Re: [mpls] FW: R: RE: Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and
> The p2p bidir connection can be co-routed, and then it is possible to
> perform e.g. loopback at intermediate nodes.
> 
> The p2p bidir connection can be associated, and then a loopback at an
> intermediate node will not be possible. But the end-to-end monitoring
> is still performed without problems.
> 
> Note that a co-routed bidir 1+1 protected connection can select it's A-
> to-Z traffic from working and its Z-to-A traffic from protection; this
> effectively creates an associated bidir connection in which e2e
> monitoring is supported but loopbacks at intermediate nodes are not
> successful.
> 
> Regards,
> Maarten
> 
> >         difference under the hood. As for uni-directional BFD, that
> is
> > a BFD WG problem
> >         at the moment.
> >
> >
> >         p2mp transport paths does not make BFD a suitable OAM
> protocol
> > for MPLS-TP nor
> >         (Proactive      Connectivity Verification, Continuity Check
> and
> > Remote Defect
> >
> >         >Numerous comments did have effect on the draft and those
> that
> > didn't were
> >         had to be balanced against comments coming from the MPLS &
> BFD
> > WGs. I would
> >         >Meanwhile as an editor of the document, I'll take the
> liberty
> > of responding
> >         >>I don't understand the need for 2 types of packets: a
> single
> > type allows CC;
> >         >>Besides adding complexity, we whether always activate both
> or
> > potentiate
> >         undetected mismerges.
> >         >
> >
> >         the exit criteria unreliable as well, not really a good
> design.
> > Hence they are
> >         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...
> >         difference under the hood. As for uni-directional BFD, that
> is
> > a BFD WG problem
> >         at the moment.
> >         >
> >
> >         >> Provisioning list
> >         particular configuration. So, i expect each draft-ietf-mpls-
> TP-
> > * to focus on
> >         talking about MPLS in general?... The TP profile is never
> quite
> > delimited.
> >         >> Does chapter 4 contain ALL the configurable parameters
> list
> > agreed to
> >         connected to anything (which as a network is rather useless)
> it
> > will be
> >         >The issue is not code point, which is the trivial part. It
> is
> > reuse of the
> >         >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach
> to
> > CC is simpler:
> >         Rx connection. An RDI, the only articulation between Rx and
> Tx
> > flows,
> >         performance reports and protection. Also to allow scaling,
> more
> > implementation
> >         >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes
> more
> > and more
> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-
> cc-
> > cv-rdi-05.txt>
> >         >>Several service providers regarded this draft as not
> meeting
> > their
> >         >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
> >         it said on the tin up front, and IMO why when the IETF
> started
> > down this path
> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-
> cc-
> > cv-rdi-05.txt>
> >         >Two of the three document editors were present at SG15
> plenary
> > in February
> >         >Nevertheless the MPLS WG chair decided to adopt the draft as
> a
> > WG document:
> >         >
> >         >>Several service providers regarded this draft as not
> meeting
> > their
> >         >>transport
> >         >networks' needs.
> >         >
> >
> >         >            carefully discussed between the authors and
> people
> > making the
> >         comments and
> >         >            has been resolved.
> >         >
> >         the comments. When ITU-T Q10/15 has been involved in
> discussing
> > its comments?
> >         >
> >         >
> >         >
> >         >
> >         >Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-
> > 05.txt>
> >         >      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
> >         >  The publication request for draft-ietf-mpls-tp-cc-cv-rdi
> was
> > sent
> >         >  June 29th.
> >         >
> >         >  comments. Version -05 was published on June 29 and the
> IETF
> > last call
> >         >Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-
> > 05.txt>
> >         from which that report was generated and has been augmented
> to
> > include the BFD
> >
> >         >From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Rui
> >         Costa
> >         >Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-
> > 05.txt>
> >
> >         >From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of The
> >         IESG
> >         >   Defect Indication functionalities are required for MPLS-
> TP
> > OAM.
> >         >
> >         >   switched path between sink and source for any
> connectivity
> > issues.
> >         >   Remote defect indication enables an End Point to report,
> to
> > its

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Jul 2011 13:57:01 -0700

Dear Maarten,
I hope you can help me to interpret the following text from the TD 377
(PLEN/15), Geneva, 14-25 February 2011:
"The MPLS-TP OAM mechanisms as described in this Recommendation apply
to co-routed bidirectional point-to-point MPLS-TP connections.
Unidirectional point-to-point and point-to-multipoint MPLS-TP
connections will be addressed in a future version of this
Recommendation."

Regards,
Greg

On Wed, Jul 27, 2011 at 1:16 PM, Maarten vissers
<[email-masked]> wrote:
>> >         >I would not go so far as to say "similar to 1731", there is
>> > actually a lot of
>> >         >----Messaggio originale----
>> >         >Da: [email-masked]
>> >
>> >         >Data: 8-lug-2011 18.13
>> >         >A: "Rui Costa"<[email-masked]>, "Stewart
>> > Bryant"<[email-masked]>
>> >         >Cc:
>> >         >Ogg: RE: [mpls] Last Call: &lt;draft-ietf-mpls-tp-cc-cv-rdi-
>> > 05.txt&gt;
>> >
>> >         >
>> >         >Rui:
>> >         >
>> >         >You wrote:
>> >         >
>> >         >>Reading something, keeping it on record, without effect in
>> > the draft and
>> >         >>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
>> >         >
>> >         >Meanwhile as an editor of the document, I'll take the
>> liberty
>> > of responding
>> >         >
>> >         >>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;
>> >         >>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
>> >         >
>> >         >>(BTW: can't understand how we propose one ACH codepoint to
>> > CC, another for
>> >         >
>> >         >Because that puts you into two protocol ID demultiplexing
>> > steps per OAM PDU
>> >         >
>> >         >> 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
>> >         >> ...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
>> >         >
>> >         >> Provisioning list
>> >         >> This is an MPLS profile/subset (and i heard) achievable
>> > through a
>> >         >> 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
>> >         >> Does chapter 4 contain ALL the configurable parameters
>> list
>> > agreed to
>> >         >
>> >         >It should. As for encapsulations, unless TP is in a complete
>> > island not
>> >         >
>> >         >> Backwards compatibility
>> >         >> This was the main argument risen to ground MPLS-TP OAM on
>> > BFD. It's not a
>> >         >> For reasons like the above, however, MPLS-TP BFD won't be
>> > backwards
>> >         >
>> >         >The issue is not code point, which is the trivial part. It
>> is
>> > reuse of the
>> >         >
>> >         >>Simplicity
>> >         >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach
>> to
>> > CC is simpler:
>> >         >>auto/negotiated -) means OK. A standard defined number of
>> > misses means lost
>> >         >>pear to identify Tx problems.
>> >         >>This OAM simplicity is the key for reliable fail finger
>> > pointing,
>> >         >>operators.
>> >         >
>> >         >Well IMO there was not a lot of interest in T-MPLS until the
>> > IETF was going
>> >         >
>> >         >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes
>> more
>> > and more
>> >         >
>> >         >That is because MPLS-TP is not a new techology, it is an
>> > addition to the
>> >         >
>> >         >Hope this helps
>> >         >D
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >         >From: David Allan I [mailto:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 19:25
>> >
>> >         >To: [email-masked]; Rui Costa; [email-masked];
>> > IETF-Announce
>> >         >Cc: [email-masked]
>> >
>> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-
>> cc-
>> > cv-rdi-05.txt>
>> >         >
>> >         >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
>> >         >
>> >         >However this is a consequence of adapting an existing
>> > technology to a new
>> >         >
>> >         >My 2 cents
>> >         >Dave
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >         >From: David Allan I [mailto:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 18:36
>> >
>> >         >To: [email-masked]; [email-masked]; Rui Costa
>> >         >Cc: [email-masked]; [email-masked]; IETF-Announce
>> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-
>> cc-
>> > cv-rdi-05.txt>
>> >         >
>> >         >Hi Erminio:
>> >         >
>> >         >Two of the three document editors were present at SG15
>> plenary
>> > in February
>> >         >
>> >         >Cheers
>> >         >Dave
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >         >From: [email-masked]
>> > [mailto:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 18:34
>> >
>> >         >To: Rui Costa; [email-masked]; IETF-Announce
>> >         >Cc: [email-masked]
>> >
>> >         >Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
>> > rdi-05.txt>
>> >         >
>> >         >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
>> >         >
>> >         >http://www.ietf.org/mail-
>> > archive/web/mpls/current/msg04502.html
>> >         >
>> >         >The lack of consensus was motivated by serious technical
>> > concerns raised by
>> >         >
>> >         >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: [email-masked]
>> > [mailto:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 18:26
>> >
>> >         >To: [email-masked]; Rui Costa
>> >         >Cc: [email-masked]; [email-masked]; IETF-Announce
>> >         >Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
>> > rdi-05.txt>
>> >         >
>> >         >>  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
>> >         >
>> >         >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
>> >         >
>> >         >
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >         >From: Loa Andersson [mailto:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 16:44
>> >         >To: Rui Costa
>> >
>> >         >Cc: [email-masked]; IETF-Announce; [email-masked]
>> >
>> >         >Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
>> rdi-
>> > 05.txt>
>> >         >
>> >         >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:[email-masked]]
>> >         >Sent: quarta-feira, 6 de Julho de 2011 14:58
>> >
>> >         >To: Rui Costa; [email-masked]; IETF-Announce
>> >         >Cc: [email-masked]
>> >
>> >         >Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
>> rdi-
>> > 05.txt>
>> >         >
>> >         >Hi Rui:
>> >         >
>> >         >The comments were not ignored, the resolution of the Q10
>> > comments as well as
>> >
>> >         >
>> >         >So you know...
>> >         >Dave
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >
>> >         >From: [email-masked] [mailto:[email-masked]]
>> On
>> > Behalf Of Rui
>> >         Costa
>> >         >Sent: segunda-feira, 4 de Julho de 2011 23:03
>> >
>> >         >To: [email-masked]; IETF-Announce
>> >         >Cc: [email-masked]
>> >         >Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
>> rdi-
>> > 05.txt>
>> >
>> >         >
>> >         >IMHO and for the record:
>> >         >
>> >         >ITU-T comments regarding this draft haven't been discussed
>> > with ITU-T but
>> >         >
>> >         >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
>> >         >When was the WG LC launched, to verify LC comments
>> > resolution?]
>> >         >
>> >         >Regards,
>> >         >Rui
>> >         >
>> >         >
>> >         >-----Original Message-----
>> >         >From: [email-masked] [mailto:[email-masked]]
>> On
>> > Behalf Of The
>> >         IESG
>> >         >Sent: quinta-feira, 30 de Junho de 2011 14:47
>> >         >To: IETF-Announce
>> >         >Cc: [email-masked]
>> >
>> >         >Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-
>> > 05.txt> (Proactive
>> >
>> >         >
>> >         >
>> >         >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
>> >         >[email-masked] mailing lists by 2011-07-14. Exceptionally,
>> > comments may be
>> >         >sent to [email-masked] 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
>> >         >[email-masked]
>> >         >https://www.ietf.org/mailman/listinfo/mpls
>> >         >
>> >         >
>> >
>> >         >_______________________________________________
>> >         >Ietf mailing list
>> >         >[email-masked]
>> >         >https://www.ietf.org/mailman/listinfo/ietf
>> >
>> >         >
>> >
>> >

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 15:03:28 -0700

Maarten,

Actually it doesn't.  G.8113.1, absent an IP forwarding capability, has no ability to send replies from egress to ingress for unidirectional LSP constructs.

Thanks,

John

Sent from my iPhone

> Maarten vissers
> Sent: Wednesday, July 27, 2011 1:17 PM
> To: Gregory Mirsky; [email-masked]
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Eric Gray
> > > Sent: 27 July 2011 18:32
> > > To: [email-masked]
> > > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to
> CCM
> > is
> > >         >I would not go so far as to say "similar to 1731", there
> is
> > > actually a lot of
> > >         >Ogg: RE: [mpls] Last Call: &lt;draft-ietf-mpls-tp-cc-cv-
> rdi-
> > > 05.txt&gt;
> > >
> > >         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
> > >         translate "ingored" or "without effect" to "did not get
> one'e
> > > way". In the
> > >         >>...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
> > >         separated using different ACH code points and the receiver
> is
> > > obliged to
> > >         >>(BTW: can't understand how we propose one ACH codepoint
> to
> > > CC, another for
> > >         the state variables we really need, bringing us to
> something
> > > similar to 1731,
> > >         >I would not go so far as to say "similar to 1731", there
> is
> > > actually a lot of
> > >         >> 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
> > >         >It should. As for encapsulations, unless TP is in a
> complete
> > > island not
> > >         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
> > >         >> For reasons like the above, however, MPLS-TP BFD won't
> be
> > > backwards
> > >         >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
> > >         application. I do not see any way around that. And the
> entire
> > > joint project was
> > >         packet transport transitioned from being a minority sport
> to
> > > mainstream, so it
> > >         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
> > >         >
> > >         >
> > >         >
> > >         >
> > >
> > >         >Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-
> cv-
> > > rdi-05.txt>
> > >         >The poll for its adoption as a WG document was halted by
> the
> > > MPLS WG chair
> > >         >After several WG revisions and WG LCs, the technical
> issues
> > > have not been
> > >         resolved.
> > >         >
> > >
> > >         >Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-
> cv-
> > > rdi-05.txt>
> > >         >            It has also passed a working roup call to
> verify
> > > that LC comments
> > >         >But it seems that some comments have not been discussed
> with
> > > the authors of
> > >         >working group last call; these  comments - and the
> intended
> > > resolution -
> > >         >  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
> > >         >  The AD review resulted in a "New ID needed" due to
> mostly
> > > editorial
> > >         >The v04 draft addressing WG LC comments was published on
> the
> > > 28th June (same
> > >         Connectivity Verification, Continuity Check and Remote
> Defect
> > > indication for
> > >         >The IESG has received a request from the Multiprotocol
> Label
> > > Switching WG
> > >         >- 'Proactive Connectivity Verification, Continuity Check
> and
> > > Remote
> > >         >The IESG plans to make a decision in the next few weeks,
> and
> > > solicits
> > >         >sent to [email-masked] instead. In either case, please
> retain
> > > the
> > >         >   Continuity Check, Proactive Connectivity Verification
> and
> > > Remote
> > >         >   Continuity Check monitors the integrity of the
> continuity
> > > of the
> > >         >   verification monitors the integrity of the routing of
> the
> > > label
> > >         >   associated End Point, a fault or defect condition that
> it
> > > detects on
> > >         >   This document specifies methods for proactive
> continuity
> > > check,
> > >         >   continuity verification, and remote defect indication
> for
> > > MPLS-TP
> > >         >No IPR declarations have been submitted directly on this
> I-
> > D.

---

From: Maarten vissers <[email-masked]>
Date: Wed, 27 Jul 2011 22:09:33 +0000

Dear Greg,

You asked for G.8113.1 CCM applicability. The CCM applies to the four connection types I have listed; i.e. no additions are necessary to support the lower three connection types in my list. Rationale is that CCM is 1-way OAM with processing at MEPs (i.e. endpoints) only. It is just not documented today, but it can be inferred from looking at applicability of CC-CV-RDI type OAM deployed in other transport technologies.

As I have indicated in my first response, G.8113.1 loopback will not work in absence of a return path. Also other 2-way OAM will not work in unidir LSPs. Furthermore, any other 2-way OAM reflected at an intermediate point in the LSP connection in associated bidir LSPs will not work (but will work if reflected at end point, i.e. at a MEP). But any type of 1-way OAM will work for all four connection types.

Thus solutions for 2-way OAM are not readily available in G.8113.1 for unidir p2p and unidir p2mp and associated bidir p2p at intermediate points.

Hope this clarifies.
Regards,
Maarten

> Sent: 27 July 2011 22:57
> To: Maarten vissers
> Cc: Gregory Mirsky; [email-masked]
> >> >         org"<[email-masked]>, "[email-masked]"<[email-masked]>,
> "IETF-
> >> > Announce"<ietf-
> >> >         [email-masked]>
> >> >         could carry it in every packet and have the receiver
> simply
> >> > ignore most of
> >> >         CV, [counting other drafts, another for frame loss ...]
> but
> >> > don't consider
> >> >         compatible with previous BFD (even considering just
> CC/CV).
> >> > They don't even
> >> >         not see a need for, and that they considered any
> additional
> >> > functionality
> >> >         parasitic.
> >> >         >
> >> >         where the comments originated. The revised meeting
> schedule
> >> > resulted in a day

---

From: Maarten vissers <[email-masked]>
Date: Wed, 27 Jul 2011 22:16:43 +0000

John,

See my response to Greg a minute ago.

In addition, have a look at e.g. PDH, SDH, ATM and OTN OAM. There is no requirement in transport networks to send RDI from MEP sink to MEP source function. Such requirement does not exist in MPLS-TP transport networks either. RDI is used to support bidirectional performance monitoring at transport service layer. Unidir PW/service-LSP connections are not required/unable to support bidir perf mon. So it is wasteful to try to send RDI from sink to source in unidir connections.

Regards,
Maarten

> From: John E Drake [mailto:[email-masked]]
> Sent: 28 July 2011 00:03
> To: Maarten vissers; Gregory Mirsky; [email-masked]
> Actually it doesn't.  G.8113.1, absent an IP forwarding capability, has
> no ability to send replies from egress to ingress for unidirectional
> LSP constructs.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> 
> > > G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p
> unidir,
> > > p2mp unidir connections.
> > >
> > > Note that a co-routed bidir 1+1 protected connection can select
> it's
> > A-
> > > >         >>...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;
> > > >         >
> > > >
> > > >         >We want CV all the time so that any misconectivity can
> be
> > > > detected, but on
> > > >         >Because that puts you into two protocol ID
> demultiplexing
> > > > steps per OAM PDU
> > > >         >> ...eliminating the session "state variable" (down,
> init,
> > > > up), aiming just
> > > >         >> This is an MPLS profile/subset (and i heard)
> achievable
> > > > through a
> > > >         >>auto/negotiated -) means OK. A standard defined number
> of
> > > > misses means lost
> > > >         >To: [email-masked]; Rui Costa;
> [email-masked];
> > > > IETF-Announce
> > > >         >Cc: [email-masked]
> > > >
> > > >         >E> This is a true statement: the solution in this draft
> is
> > > > useless for many
> > > >         MPLS- TP deployments.
> > > >         >
> > > >
> > > >         >Nevertheless the MPLS WG chair decided to adopt the
> draft
> > as
> > > a
> > > > WG document:
> > > >         >
> > > >         >So when the WG LC to confirm the LC comment resolution
> has
> > > > been launched?
> > > >         >
> > > >         >The proto write-up says:
> > > >         >
> > > >         >The history of draft-ietf-mpls-tp-cc-cv-rdi working
> group
> > > > review
> > > >         >process is:
> > > >         >
> > > >         >  The authors have since worked hard to resolve
> comments,
> > > some
> > > >         >  issue has been brought to the working group mailing
> list
> > > for
> > > >         >  resolution.
> > > >         >
> > > >         >  The current list of Last Call Comments resoltion is
> also
> > > > avaiable at:
> > > >         >  The list of issues that the authors kept very
> carefully,
> > > > shows without
> > > >         >doubt
> > > >         those collected from the MPLS WG was presented at the
> last
> > > > IETF. My spreadsheet
> > > >
> > > >         >ITU-T comments regarding this draft haven't been
> discussed
> > > > with ITU-T but
> > > >         >Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-
> rdi-
> > > > 05.txt> (Proactive
> > > >
> > > >         >[email-masked] mailing lists by 2011-07-14.
> Exceptionally,
> > > > comments may be
> > > >         >   label switched path for any loss of continuity
> defect.
> > > > Connectivity
> > > >         >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-
> cv-
> > > rdi/
> > > >         >
> > > >         >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-
> cv-
> > > rdi/
> > > >         >
> > > >         >

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 28 Jul 2011 00:19:39 +0200

Hi John,

> Actually it doesn't.  G.8113.1, absent an IP forwarding capability, has no ability to send replies from egress to ingress for unidirectional LSP constructs.

How does draft-ietf-mpls-tp-cc-cv-rdi do it under the same 
circumstances?       Use an iPhone? ;)

Cheers, Huub.

>> Subject: Re: [mpls] FW: R: RE: Last Call:<draft-ietf-mpls-tp-cc-cv-
>>> Subject: RE: [mpls] FW: R: RE: Last Call:<draft-ietf-mpls-tp-cc-cv-
>>> Subject: Re: [mpls] FW: R: RE: Last Call:<draft-ietf-mpls-tp-cc-cv-
>>>> Subject: [mpls] FW: R: RE: Last Call:<draft-ietf-mpls-tp-cc-cv-
>> rdi-
>>>> Subject: Re: [mpls] R: RE: Last Call:<draft-ietf-mpls-tp-cc-cv-
>> rdi-
>>>>          >Ogg: RE: [mpls] Last Call:&lt;draft-ietf-mpls-tp-cc-cv-
>> rdi-
>>>> 05.txt&gt;
>>>>
>>>>          had to be balanced against comments coming from the MPLS&
>>> BFD
>>>> WGs. I would
>>>>          assigning 1 single ACH protocol identifier codepoint>as
>>>> requested by ITU-T)
>>>>          >
>>>>
>>>>          >Subject: RE: [mpls] R: Re: Last Call:<draft-ietf-mpls-tp-
>>> cc-
>>>> cv-rdi-05.txt>
>>>>          >Subject: RE: [mpls] R: Re: Last Call:<draft-ietf-mpls-tp-
>>> cc-
>>>> cv-rdi-05.txt>
>>>>          >Subject: R: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-
>> cv-
>>>> rdi-05.txt>
>>>>          >Subject: R: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-
>> cv-
>>>> rdi-05.txt>
>>>>          >Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-
>>> rdi-
>>>> 05.txt>
>>>>          >Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-
>>> rdi-
>>>> 05.txt>
>>>> Last-Call-Comments<http://www.pi.nu/%7Eloa/cc-cv-rdi-Last-Call-
>>>> Comments>  .
>>>>          xls
>>>>          >
>>>>
>>>>          >So you know...
>>>>          >Dave
>>>>          >
>>>>          >
>>>>          >Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-
>>> rdi-
>>>> 05.txt>
>>>>
>>>>          >Subject: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-
>>>> 05.txt>  (Proactive
>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Jul 2011 15:21:21 -0700

Dear Maarten,
I hope too that we can agree that the current version of the G.8113.1
does not address MPLS-TP constructs other than bi-directional
co-routed p2p LSP. What other MPLS-TP constructs (bi-directional
associated p2p LSP, unidirectional p2p and p2mp LSP, Segment, Section
and PW) and when the G.8113.1 might address in the future is outside
of this discussion.

Regards,
Greg

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 15:33:04 -0700

Hi,

I think Greg has it just about right.  Cc-cv-rdi specifically acknowledges that unicast (p2p and p2mp) is FFS.  The proponents of G.8113.1 claim, evidence to the contrary, that it addresses unicast.

Thanks,

John

Sent from my iPhone

> Greg Mirsky
> Sent: Wednesday, July 27, 2011 3:21 PM
> To: Maarten vissers
> Cc: [email-masked]
> > You asked for G.8113.1 CCM applicability. The CCM applies to the four
> connection types I have listed; i.e. no additions are necessary to
> support the lower three connection types in my list. Rationale is that
> CCM is 1-way OAM with processing at MEPs (i.e. endpoints) only. It is
> just not documented today, but it can be inferred from looking at
> applicability of CC-CV-RDI type OAM deployed in other transport
> technologies.
> >
> > As I have indicated in my first response, G.8113.1 loopback will not
> work in absence of a return path. Also other 2-way OAM will not work in
> unidir LSPs. Furthermore, any other 2-way OAM reflected at an
> intermediate point in the LSP connection in associated bidir LSPs will
> not work (but will work if reflected at end point, i.e. at a MEP). But
> any type of 1-way OAM will work for all four connection types.
> >
> > Thus solutions for 2-way OAM are not readily available in G.8113.1
> for unidir p2p and unidir p2mp and associated bidir p2p at intermediate
> points.
> >
> > Hope this clarifies.
> > Regards,
> > Maarten
> >
> >> >> The G.8113.1 addresses only bi-directional co-routed LSP and has
> no
> >> model to
> >> >> rdi-05.txt> (Proactive Connectivity Verification, Continuity
> Check
> >> and
> >> >> you've listed but only compare with corresponding CCM addressed
> in
> >> CC-
> >> >> CV-RDI.
> >> >>
> >> >> Regards,
> >> >> Greg
> >> >> rdi-05.txt> (Proactive Connectivity Verification, Continuity
> Check
> >> and
> >> >> The p2p bidir connection can be co-routed, and then it is
> possible
> >> to
> >> >> The p2p bidir connection can be associated, and then a loopback
> at
> >> an
> >> >> > Subject: [mpls] FW: R: RE: Last Call: <draft-ietf-mpls-tp-cc-
> cv-
> >> rdi-
> >> >> > Subject: Re: [mpls] R: RE: Last Call: <draft-ietf-mpls-tp-cc-
> cv-
> >> rdi-
> >> >> > is not capable to solve these issues? I don't think so.
> Solutions
> >> are
> >> >> >         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
> >> >> >         them, but then that would make the defect entry
> criteria
> >> >> > compeltely random and
> >> >> >         process every source MEP TLV it receives. I hope this
> is
> >> >> clear.
> >> >> >         >
> >> >> >
> >> >> >         assigning 1 single ACH protocol identifier codepoint
> >as
> >> >> > requested by ITU-T)
> >> >> >         >
> >> >> >
> >> >> >         >> ...using IP to create the reverse way, which we
> cannot
> >> >> > assume per
> >> >> >         requirements;
> >> >> >         intention of tool development was that what resulted
> was
> >> >> > applicable to the
> >> >> >         >The issue is not code point, which is the trivial
> part.
> >> It
> >> >> is
> >> >> > reuse of the
> >> >> >         in each flow, a standard defined nr of constant
> heartbeat
> >> >> > signals (with
> >> >> >         >>This OAM simplicity is the key for reliable fail
> finger
> >> >> > pointing,
> >> >> >         >That is because MPLS-TP is not a new techology, it is
> an
> >> >> > addition to the
> >> >> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-
> mpls-
> >> tp-
> >> >> cc-
> >> >> > cv-rdi-05.txt>
> >> >> >         exceeded their requirements in that there was
> additional
> >> >> > functionality they did
> >> >> >         based on the premise of engineering re-use not
> greenfield
> >> >> > design. That is what
> >> >> >         >Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-
> mpls-
> >> tp-
> >> >> cc-
> >> >> > cv-rdi-05.txt>
> >> >> >         >The lack of consensus was motivated by serious
> technical
> >> >> > concerns raised by
> >> >> >         >This is a true statement: the solution in this draft
> is
> >> >> > useless for many
> >> >> >         MPLS- TP deployments.
> >> >> >
> >> >> >         >
> >> >> >         >
> >> >> >         >>  The publication request for draft-ietf-mpls-tp-cc-
> cv-
> >> rdi
> >> >> > was  sent
> >> >> >         >> June 29th.
> >> >> >         >>
> >> >> >         >
> >> >> >         >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some
> details
> >> >> > below.
> >> >> >         >
> >> >> >         >  The publication request for draft-ietf-mpls-tp-cc-
> cv-
> >> rdi
> >> >> was
> >> >> > sent
> >> >> >         >  June 29th.
> >> >> >         >
> >> >> >         >The comments were not ignored, the resolution of the
> Q10
> >> >> > comments as well as
> >> >> >
> >> >> >         WG comments is available at http://www.pi.nu/~loa/cc-
> cv-
> >> rdi-
> >> >> >         >   label switched paths, pseudo wires and Sections
> using
> >> >> > Bidirectional
> >> >> >         >   Forwarding Detection.
> >> >> >         >
> >> >> >         >