Re: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org , IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-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] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, i...@ietf.org , IETF-Announceietf-announce@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan
Erminio Hi, I belong to an Operator, I strongly agree with Greg. Regards Medel From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, July 14, 2011 10:50 AM To: erminio.ottone...@libero.it Cc: m...@ietf.org; IETF-Announce; ietf@ietf.org Subject: Re: [mpls] R: RE: R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. Every generalization is wrong, including this one Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it erminio.ottone...@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? Messaggio originale Da: nurit.sprec...@nsn.com Data: 7-lug-2011 11.59 A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.org Ogg: RE: [mpls] R: Re: LastCall: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive ConnectivityVerification,Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point. Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
