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
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; ietf@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; ietf@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; ietf@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
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
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. I disagree. From a backward compatibility perspecting the codepoint is very relevant. An existing implementation does not reckon the new encapsulation: the only way to deploy this solution in a backward compatible manner is by upgrading all the IP/MPLS nodes that have been deployed up to so far. I think that the reuse of the majority of the implementation is actually the issue. Those implementations do not have the capabilities required to be deployed in a transport network. Developing a non-transport capable standard will not make these boxes transport capable but it would just make the standard useless for a transport environment. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (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
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
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; ietf@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
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
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
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
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. I disagree. From a backward compatibility perspecting the codepoint is very relevant. An existing implementation does not reckon the new encapsulation: the only way to deploy this solution in a backward compatible manner is by upgrading all the IP/MPLS nodes that have been deployed up to so far. I think that the reuse of the majority of the implementation is actually the issue. Those implementations do not have the capabilities required to be deployed in a transport network. Developing a non-transport capable standard will not make these boxes transport capable but it would just make the standard useless for a transport environment. Messaggio originale Da: david.i.al...@ericsson.com Data: 8-lug-2011 18.13 A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf. orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf- annou...@ietf.org Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (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
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
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; ietf@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; ietf@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; ietf@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; ietf@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
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
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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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; ietf@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; ietf@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
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
, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint as requested by ITU-T) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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 E 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; ietf@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; ietf@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
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
Profile) to Proposed Standard David, 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. Stewart, 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; ...in a comparison session that took place during that same ITU-T meeting. 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. (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) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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 E 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
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
. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@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 David, 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. Stewart, 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; ...in a comparison session that took place during that same ITU-T meeting. 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. (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) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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 E 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
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
...@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 E 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; ietf@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; ietf@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; ietf@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: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf
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
-* 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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; ietf@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; ietf@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
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
, 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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; ietf@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; ietf@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; ietf@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
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
in our work, so i'm also free to write what i did. Stewart, 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; ...in a comparison session that took place during that same ITU-T meeting. 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. (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) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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
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
delimited. Does chapter 4 contain ALL the configurable parameters list agreed to provide in the comparison session? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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; ietf@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; ietf@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
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
in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@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 David, 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. Stewart, 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; ...in a comparison session that took place during that same ITU-T meeting. 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. (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) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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
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? Messaggio originale Da: l...@pi.nu Data: 6-lug-2011 17.44 A: Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: Re: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (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 On 2011-07-05 00:02, Rui Costa wrote: 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 ietf@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
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. Messaggio originale Da: rco...@ptinovacao.pt Data: 5-lug-2011 0.02 A: ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: Re: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defect indication for MPLSTransport 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 ietf@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 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
David, 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. Stewart, 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; ...in a comparison session that took place during that same ITU-T meeting. 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. (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) 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) 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? 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. 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. IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. Regards, Rui -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; ietf@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
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: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: Monday, July 04, 2011 3:03 PM To: ietf@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 ietf@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 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 On 2011-07-05 00:02, Rui Costa wrote: 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 ietf@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 ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13
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 ietf@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 Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
