Subject: Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Sep 2021 08:38:05 -0400

Med,

On Wed, Sep 01, 2021 at 06:48:43AM +0000, [email-masked] 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

---

From: <[email-masked]>
Date: Wed, 1 Sep 2021 13:21:03 +0000

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:[email-masked]]
> Envoyé : mercredi 1 septembre 2021 14:38
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Greg Mirsky <[email-masked]>; draft-ietf-opsawg-l3sm-
> [email-masked]; opsawg <[email-masked]>; rtg-bfd WG <rtg-
> [email-masked]>
> Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> 
> Med,
> 
> > 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.
> 
> > 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.
> 

_________________________________________________________________________________________________________________________

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.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Sep 2021 06:25:12 -0700

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

Regards,
Greg

On Wed, Sep 1, 2021 at 6:21 AM <[email-masked]> wrote:

> 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.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Sep 2021 11:09:10 -0400

Med,

> If there are any other comments, please let us know. 

That's what I get for not reviewing the datatracker.  

I'll flag this with your shepherding AD.  Thanks.

-- Jeff

---

From: tom petch <[email-masked]>
Date: Wed, 1 Sep 2021 15:43:49 +0000

From: OPSAWG <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Sent: 01 September 2021 16:09

Med,

<tp>

Jeff

You won't find it in the datatracker but you would in the archives of the Last Call list that I commented on this I-D to the effect that it overlaps the work of many IETF WG but does not build on that, rather takes a different direction, sometimes amending the protocol I-D/RFC.  The biggest divergence was, I think, for BGP but most routing protocols diverged to some extent (I did not look at the VPN but note that the document shepherd recommended inviting them to comment).  I missed this one for BFD, which is one of the protocols I did look at, so my analysis is doubtless incomplete.

Tom Petch

-- Jeff

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Fri, 3 Sep 2021 07:35:31 +0000

Hi Greg,

FWIW, the agreed changes are now implemented in the module. You can track them at:
https://github.com/IETF-OPSAWG-WG/lxnm/commit/9b97016743a355f2b7737288dfaedebcdc47c9b8

Also, made the companion changes to the I-D: https://tinyurl.com/l3nm-latest

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : mercredi 1 septembre 2021 15:25
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Jeffrey Haas <[email-masked]>; [email-masked]; opsawg <[email-masked]>; rtg-bfd WG <[email-masked]>
Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Hi Med,

Regards,
Greg

On Wed, Sep 1, 2021 at 6:21 AM <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Thank you.

Cheers,
Med

> De : Jeffrey Haas [mailto:[email-masked]<mailto:[email-masked]>]
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
> Cc : Greg Mirsky <[email-masked]<mailto:[email-masked]>>; draft-ietf-opsawg-l3sm-
> [email-masked]<mailto:[email-masked]>; opsawg <[email-masked]<mailto:[email-masked]>>; rtg-bfd WG <rtg-
> [email-masked]<mailto:[email-masked]>>
> On Wed, Sep 01, 2021 at 06:48:43AM +0000,
> [email-masked]<mailto:[email-masked]> wrote:
> > Hi Jeff,
> >

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Sep 2021 14:34:45 -0700

Hi Med,
thank you for your thoughtful consideration of my comments. I have another
question about the significance of the local-multiplier (formerly
detection-multiplier). The description seems not changed and it states:
                        "The detection interval for the BFD session
                         is calculated by multiplying the value of
                         the negotiated transmission interval by
                         the detection multiplier value.";
I will note that the detection multiplier value used by a BFD system to
calculate the Detection Time is not its local Detection Multiplier but the
value of the Detect Mult field in the received BFD control packet. In other
words, that is the local-multiplier of the remote BFD peer. Section 6.8.4
in RFC 5880 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>
describes how the Detection Time is calculated for "classic" p2p BFD. Note,
the Detection Time for a MultipointTail in p2mp session is calculated
differently, according to Section 5.11 RFC 8562.

Regards,
Greg

On Fri, Sep 3, 2021 at 12:35 AM <[email-masked]> wrote:

> *De :* Greg Mirsky [mailto:[email-masked]]
> *Envoyé :* mercredi 1 septembre 2021 15:25
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* Jeffrey Haas <[email-masked]>; [email-masked];
> opsawg <[email-masked]>; rtg-bfd WG <[email-masked]>
> *Objet :* Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Hi Med,
>
> > [email-masked] wrote:
> > > Hi Jeff,
> > >

---

From: <[email-masked]>
Date: Wed, 8 Sep 2021 05:51:25 +0000

Hi Greg,

Thank you for checking.

Updated the description to avoid the confusion by referring to the remote system. The NEW description looks as follows:

       "Specifies the detection multiplier that is
        transmitted to a BFD peer.

        The detection interval for the receiving
        BFD peer is calculated by multiplying the value
        of the negotiated transmission interval by
        the received detection multiplier value.";

Please note that we only cite 6.8.4 of 5880 to be aligned with the (new) BFD session-types defined in the common module.

Cheers,
Med

Envoyé : mardi 7 septembre 2021 23:35

Hi Med,
thank you for your thoughtful consideration of my comments. I have another question about the significance of the local-multiplier (formerly detection-multiplier). The description seems not changed and it states:
                        "The detection interval for the BFD session
                         is calculated by multiplying the value of
                         the negotiated transmission interval by
                         the detection multiplier value.";
I will note that the detection multiplier value used by a BFD system to calculate the Detection Time is not its local Detection Multiplier but the value of the Detect Mult field in the received BFD control packet. In other words, that is the local-multiplier of the remote BFD peer. Section 6.8.4 in RFC 5880<https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4> describes how the Detection Time is calculated for "classic" p2p BFD. Note, the Detection Time for a MultipointTail in p2mp session is calculated differently, according to Section 5.11 RFC 8562.

Regards,
Greg

On Fri, Sep 3, 2021 at 12:35 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 1 septembre 2021 15:25
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : Jeffrey Haas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; opsawg <[email-masked]<mailto:[email-masked]>>; rtg-bfd WG <[email-masked]<mailto:[email-masked]>>
Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Hi Med,

Regards,
Greg

Thank you.

Cheers,
Med

Thank you.