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, erminio.ottone...@libero.it < erminio.ottone...@libero.it> 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: david.i.al...@ericsson.com > >Data: 8-lug-2011 18.13 > >A: "Rui Costa"<rco...@ptinovacao.pt>, "Stewart Bryant"<stbry...@cisco.com > > > >Cc: "erminio.ottone...@libero.it"<erminio.ottone...@libero.it>, > "mpls@ietf. > org"<m...@ietf.org>, "i...@ietf.org"<i...@ietf.org>, "IETF-Announce"<ietf- > annou...@ietf.org> > >Ogg: 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. > > > >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:david.i.al...@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > >To: erminio.ottone...@libero.it; Rui Costa; i...@ietf.org; IETF-Announce > >Cc: m...@ietf.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.i.al...@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > >To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa > >Cc: m...@ietf.org; i...@ietf.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.ottone...@libero.it [mailto:erminio.ottone...@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > >To: Rui Costa; i...@ietf.org; IETF-Announce > >Cc: m...@ietf.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.ottone...@libero.it [mailto:erminio.ottone...@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > >To: l...@pi.nu; Rui Costa > >Cc: m...@ietf.org; i...@ietf.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:l...@pi.nu] > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > >To: Rui Costa > >Cc: i...@ietf.org; IETF-Announce; m...@ietf.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.i.al...@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > >To: Rui Costa; i...@ietf.org; IETF-Announce > >Cc: m...@ietf.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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Rui > Costa > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > >To: i...@ietf.org; IETF-Announce > >Cc: m...@ietf.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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of > The > IESG > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > >To: IETF-Announce > >Cc: m...@ietf.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 > >i...@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be > >sent to i...@ietf.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 > >m...@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > >_______________________________________________ > >Ietf mailing list > >i...@ietf.org > >https://www.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > mpls mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
