Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky <[e-mail]>]

Hi Med,
thank you for your thoughtful consideration of my late comments.

Regards,
Greg

On Wed, Sep 1, 2021 at 6:21 AM <[e-mail]> 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:[e-mail]]
> > Envoyé : mercredi 1 septembre 2021 14:38
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> > Cc : Greg Mirsky <[e-mail]>; draft-ietf-opsawg-l3sm-
> > [e-mail]; opsawg <[e-mail]>; rtg-bfd WG <rtg-
> > [e-mail]>
> > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> >
> > Med,
> >
> > On Wed, Sep 01, 2021 at 06:48:43AM +0000,
> > [e-mail] 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.
>
>