R: 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 Standa
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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@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 indication for MPLSTransport 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
R: 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 Standa
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 This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF-Announceietf-announce@ietf.org Cc: m...@ietf.orgm...@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 indication for MPLSTransport 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
