Hi, IMHO, it would make sense to wait maybe until IETF89 to decide about merging node protect with basic rLFA spec. I think we could progress quite fast on node protection and two IETF meetings (88, 89) would be fine to have a good view and where we are on node protection maturity. Then we may decide if merge is possible or not. These two meetings would also permit to stabilize the rLFA base spec details and have consensus on the required level of details that are missing today.
I think now it's a bit early to decide ... Feedbacks ? especially from chairs ? --- Stephane -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Hannes Gredler Envoyé : lundi 7 octobre 2013 14:30 À : Jeff Tantsura Cc : [email protected] Objet : Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt jeff, i am happy to do this [rlfa single-spec for link and node-protection] unfortunately the current editor of the rlfa base spec is a bit <cough, cough> reluctant to incorporate changes for some reason. IMO there are three roads to fix the problem: 1. keep rlfa, node protection seperate drafts 2. ask the current editor once more to incoporate the node-protection text as well as other comments from stephane (e.g. how to signal T-LDP preferred transport addresses) 3. ask WG-chairs to assign a new editor to the draft /hannes On Mon, Oct 07, 2013 at 06:35:54AM +0000, Jeff Tantsura wrote: | 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. | | From: Alia Atlas <[email protected]> | Date: Wednesday, October 2, 2013 5:26 AM | To: Hannes Gredler <[email protected]> | Cc: Jeff Tantsura <[email protected]>, | "[email protected]" <[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]> | 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'(™) 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] | >>>> https://www.ietf.org/mailman/listinfo/rtgwg | >>> | >> | > | > _______________________________________________ | > rtgwg mailing list | > [email protected] | > https://www.ietf.org/mailman/listinfo/rtgwg | > | > | | | _______________________________________________ | rtgwg mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/rtgwg | _______________________________________________ rtgwg mailing list [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
