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 Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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.allan@ericsson.com
>Data: 6-lug-2011 20.24
>A: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>, 
"RCosta@ptinovacao.pt"<RCosta@ptinovacao.pt>, "ietf@ietf.org"<ietf@ietf.org>, 
"IETF-Announce"<ietf-announce@ietf.org>
>Cc: "mpls@ietf.org"<mpls@ietf.org>
>Ogg: RE: [mpls] R: Re: Last	Call:	&lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt&gt;	
(Proactive	Connectivity	Verification,	Continuity Check and Remote Defect 
indication	for	MPLS	Transport	Profile) to Proposed Standard
>
>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


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux