Agree with the approach of having a single doc.
Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future tél. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 [email protected]<mailto:[email protected]> De : [email protected] [mailto:[email protected]] De la part de Jeff Tantsura Envoyé : lundi 7 octobre 2013 08:36 À : Alia Atlas; Hannes Gredler Cc : [email protected] Objet : Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Hi Alia/Hannes, I support very much Alia's position here and would like to see node protection as part of base rlfa spec rather than dev-team HLD pushed as standard track document. Would be great to see input from all vendors to ensure interoperability. Thanks! Cheers, Jeff From: Alia Atlas <[email protected]<mailto:[email protected]>> Date: Wednesday, October 2, 2013 5:26 AM To: Hannes Gredler <[email protected]<mailto:[email protected]>> Cc: Jeff Tantsura <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt It would be excellent to see progress on the Remote LFA draft and on merging at least the two drafts that describe how to do node-protection for Remote LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <[email protected]<mailto:[email protected]>> wrote: hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'((tm)) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now ... what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously the > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>> >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> rtgwg mailing list >>>> [email protected]<mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >> > > _______________________________________________ > rtgwg mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
