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

From: Greg Mirsky <[email-masked]>
Date: Fri, 27 Aug 2021 19:56:19 -0700

Dear Authors,
thank you for your work on this document. I've read the draft and have a
question, and a suggestion. Section 7.6.4
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
describes
how BFD is controlled in vpn-common. I've noticed that you use references
to RFC 5880. While that is the basis for all subsequent BFD documents, for
BFD YANG data model draft-ietf-bfd-yang
<https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more useful.
Perhaps the container oam can re-use grouping base-cfg-parms.
What are your thoughts?

Regards,
Greg

---

From: tom petch <[email-masked]>
Date: Sat, 28 Aug 2021 12:07:03 +0000

From: Rtg-bfd <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Sent: 28 August 2021 03:56

Dear Authors,
thank you for your work on this document. I've read the draft and have a question, and a suggestion. Section 7.6.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4> describes how BFD is controlled in vpn-common. I've noticed that you use references to RFC 5880. While that is the basis for all subsequent BFD documents, for BFD YANG data model draft-ietf-bfd-yang<https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more useful. 

<tp>
Greg

I think that the authors have got this one right (although I disagree with much else as I have commented on Last Call:-(,   If you look at the history of bfd-yang you will see that nothing has happened to it for over three years despite concerted efforts to get it moving, so in the interests of this becoming an RFC within the next three years (!), I would not want to see the reference changed.

Tom Petch

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 28 Aug 2021 12:02:53 -0700

Hi Tom,
I understand that the missref that the BFD YANG data model got into for so
long caused some frustration and uncertainty. As of late, the authors, WG
Chairs and the AD have taken actions to untangle the situation and progress
most of the data models leaving a smaller part in missreff. I don't have
first-hand information on how close to the publication of the updated main
body of the BFD YANG data model is. I hope it is not too far.
I have several questions about the BFD container
in draft-ietf-opsawg-l3sm-l3nm. I hope I can use the opportunity and ask
them even we're past the LC phase:

   - Which mode of a BFD session is assumed for the model? For example, is
   it Asynchronous or Demand; with Echo or without; single-hop or multi-hop?
   - Which BFD session types the data model is required to support? For
   example, "classic" RFC 5880, S-BFD per RFC 7880, or BFD for multipoint
   networks?
   - What behavior of a BFD system is controlled by the holdtime? Can you
   point to the text in RFC 5880 that defines the expected behavior?

Regards,
Greg

On Sat, Aug 28, 2021 at 5:07 AM tom petch <[email-masked]> wrote:

> question, and a suggestion. Section 7.6.4<
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
> describes how BFD is controlled in vpn-common. I've noticed that you use
> references to RFC 5880. While that is the basis for all subsequent BFD
> documents, for BFD YANG data model draft-ietf-bfd-yang<
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful.
>
> <tp>
> Greg
>
> I think that the authors have got this one right (although I disagree with
> much else as I have commented on Last Call:-(,   If you look at the history
> of bfd-yang you will see that nothing has happened to it for over three
> years despite concerted efforts to get it moving, so in the interests of
> this becoming an RFC within the next three years (!), I would not want to
> see the reference changed.
>
> Tom Petch
>

---

From: <[email-masked]>
Date: Mon, 30 Aug 2021 12:19:23 +0000

Hi Greg,

Thank you for checking the OAM part and for sharing this comment.

As you can read in both sections 4 and 5, this model is ** not a device configuration model **. The focus is on aspects that can be triggered by service requests and managed by the network controller. This network view of the service will be then enriched (with other sources such as local templates/profiles/defaults) to derive the exhaustive configuration that will be enforced in involved devices to deliver the requested service.

With that rationale in mind, you can understand why we don’t import device models but point to the authoritative RFCs for aspects that we think make sense to be tweaked at the network-level.

Thanks.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : samedi 28 août 2021 04:56
À : [email-masked]; opsawg <[email-masked]>; rtg-bfd WG <[email-masked]>
Objet : A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Dear Authors,
thank you for your work on this document. I've read the draft and have a question, and a suggestion. Section 7.6.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4> describes how BFD is controlled in vpn-common. I've noticed that you use references to RFC 5880. While that is the basis for all subsequent BFD documents, for BFD YANG data model draft-ietf-bfd-yang<https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more useful. Perhaps the container oam can re-use grouping base-cfg-parms.
What are your thoughts?

Regards,
Greg

_________________________________________________________________________________________________________________________

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: Mon, 30 Aug 2021 06:48:05 -0700

Hi Med,
thank you for your detailed feedback; much appreciated. I think that I now
understand better the philosophy of the model. But I will note that RFC
5880 does not cover RFC 7880 and 8562 (both have updated RFC 5880). It
seems that adding bfd-session-type could be a very useful enhancement to
the OAM container. Values for the new parameter should reflect values
defined for bfd.SessionType in RFCs 7880, 8562, and 8563:

   - SBFDInitiator;
   - SBFDReflector;
   - PointToPoint;
   - MultipointHead;
   - MultipointTail;
   - MultipointClient

And my apologies for my late comments.

Regards,
Greg

On Mon, Aug 30, 2021 at 5:19 AM <[email-masked]> wrote:

> As you can read in both sections 4 and 5, this model is ** not a device
> configuration model **. The focus is on aspects that can be triggered by
> service requests and managed by the network controller. This network view
> of the service will be then enriched (with other sources such as local
> templates/profiles/defaults) to derive the exhaustive configuration that
> will be enforced in involved devices to deliver the requested service.
>
>
>
> With that rationale in mind, you can understand why we don’t import device
> models but point to the authoritative RFCs for aspects that we think make
> sense to be tweaked at the network-level.
>
>
>
> Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:[email-masked]]
> *Envoyé :* samedi 28 août 2021 04:56
> *À :* [email-masked]; opsawg <[email-masked]>;
> rtg-bfd WG <[email-masked]>
> *Objet :* A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Dear Authors,
>
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4> describes
> <https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful. Perhaps the container oam can re-use grouping base-cfg-parms.
>
> What are your thoughts?
>
>
>
> Regards,
>
> Greg
>

---

From: <[email-masked]>
Date: Tue, 31 Aug 2021 06:54:50 +0000

Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : lundi 30 août 2021 15:48
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [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,
thank you for your detailed feedback; much appreciated. I think that I now understand better the philosophy of the model.

[Med] Great, thanks.

But I will note that RFC 5880 does not cover RFC 7880 and 8562 (both have updated RFC 5880). It seems that adding bfd-session-type could be a very useful enhancement to the OAM container. Values for the new parameter should reflect values defined for bfd.SessionType in RFCs 7880, 8562, and 8563:

  *   SBFDInitiator;
  *   SBFDReflector;
  *   PointToPoint;
  *   MultipointHead;
  *   MultipointTail;
  *   MultipointClient
[Med] I’m afraid that most of these apply between PEs, not to the CE-PE segment. No? There might be a value in controlling whether base or S-BFD is used, though.
And my apologies for my late comments.

Regards,
Greg

On Mon, Aug 30, 2021 at 5:19 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : samedi 28 août 2021 04:56
À : [email-masked]<mailto:[email-masked]>; opsawg <[email-masked]<mailto:[email-masked]>>; rtg-bfd WG <[email-masked]<mailto:[email-masked]>>
Objet : A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Dear Authors,

Regards,
Greg

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 Aug 2021 17:30:46 -0400

Med,

> With that rationale in mind, you can understand why we don’t import device models but point to the authoritative RFCs for aspects that we think make sense to be tweaked at the network-level.

Greg's suggestion is not to import a device specific model.  His suggestion
is to leverage groupings defined in the BFD yang model that have the
configuration semantics typical of most BFD implementations.

Put a different way, if you're defining BFD parameters, why would you have
different names or structures for BFD configuration elements in your module
than everyone else?

-- Jeff

---

From: <[email-masked]>
Date: Wed, 1 Sep 2021 06:48:43 +0000

Hi Jeff, 

Actually, except local-multiplier that we call detection-multiplier, the same names are used in both drafts. We can fix that one.

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. 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.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Jeffrey Haas [mailto:[email-masked]]
> Envoyé : mardi 31 août 2021 23:31
> Cc : Greg Mirsky <[email-masked]>; draft-ietf-opsawg-l3sm-
> [email-masked]; opsawg <[email-masked]>; rtg-bfd WG <rtg-
> [email-masked]>
> > As you can read in both sections 4 and 5, this model is ** not a
> device configuration model **. The focus is on aspects that can be
> triggered by service requests and managed by the network controller.
> This network view of the service will be then enriched (with other
> sources such as local templates/profiles/defaults) to derive the
> exhaustive configuration that will be enforced in involved devices
> to deliver the requested service.
> >
> > With that rationale in mind, you can understand why we don’t
> import device models but point to the authoritative RFCs for aspects
> that we think make sense to be tweaked at the network-level.
> 
> Greg's suggestion is not to import a device specific model.  His
> suggestion is to leverage groupings defined in the BFD yang model
> that have the configuration semantics typical of most BFD
> implementations.
> 
> Put a different way, if you're defining BFD parameters, why would
> you have different names or structures for BFD configuration
> elements in your module than everyone else?
> 
> -- Jeff