Hi Med, thank you for your thoughtful consideration of my late comments. Regards, Greg
On Wed, Sep 1, 2021 at 6:21 AM <mohamed.boucad...@orange.com> wrote: > Re-, > > The IETF LC was actually closed since 2021-08-06. > > Even if the IETF LC is closed, the current BFD comments will be part of > the comments we will be addressing in the next iteration. For your record, > we have already recorded the name alignment fix, the missing default > clause, holdtime explanation, and session type indication. > > If there are any other comments, please let us know. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Jeffrey Haas [mailto:jh...@pfrc.org] > > Envoyé : mercredi 1 septembre 2021 14:38 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > > Cc : Greg Mirsky <gregimir...@gmail.com>; draft-ietf-opsawg-l3sm- > > l...@ietf.org; opsawg <ops...@ietf.org>; rtg-bfd WG <rtg- > > b...@ietf.org> > > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm > > > > Med, > > > > On Wed, Sep 01, 2021 at 06:48:43AM +0000, > > mohamed.boucad...@orange.com wrote: > > > Hi Jeff, > > > > > > Actually, except local-multiplier that we call detection- > > multiplier, > > > the same names are used in both drafts. We can fix that one. > > > > Certainly a start. > > > > > Please note that we are not using the interval-config-type choice > > > given that the single case can be covered by setting > > > desired-min-tx-interval and required-min-rx-interval to the same > > value. > > > > This is true. It's also true that that style entered the BFD YANG > > model because a unified-only mechanism is what some vendors have > > implemented. If their implementations don't cover the split mode > > you're requiring them to create a deviation. > > > > > It is then straightforward to > > > map it the device module depending whether single-minimum-interval > > > feature is supported or not. We don't want to complicate the > > network > > > view of the service with such device-level features. > > > > There is always a tension between service models and the needs of > > the underlying device model. > > > > That said, you're losing the benefits of work already done. As an > > example, you're missing the default detection multiplier because > > you're doing the work yourself rather than leveraging other work. > > This means you're requiring the model users to always provision a > > paramter that is usually left as a default. > > > > Clearly the BFD Working Group can't force you to use our work in > > your model, especially if there are features that aren't a clean > > fit. That said, when it comes IETF review time, the choice to go- > > it-alone will be noted so that the YANG doctors can do an > > appropriately thorough audit. > > > > The BFD Working Group is also happy to help with review once it's > > time. > > > > -- Jeff > > > _________________________________________________________________________________________________________________________ > > 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. > >
