Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

["Scharf, Michael" <[e-mail]>]

Chiming in as author of draft-ietf-tcpm-yang-tcp ...

> -----Original Message-----
> From: OPSAWG <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Monday, September 20, 2021 9:03 AM
> To: Martin Duke <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; opsawg-
> [e-mail]
> Subject: Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-
> l3nm-11: (with DISCUSS)
> 
> Hi Martin,
> 
> Thank you for the review.
> 
> I'm very familiar with draft-ietf-tcpm-yang-tcp (as you can see in the ACK
> section of that document).
> 
> The structure in draft-ietf-opsawg-l3sm-l3nm follows the one in draft-ietf-
> idr-bgp-model:
> 
> draft-ietf-opsawg-l3sm-l3nm
> 
>   |     |  |     +--rw (option)?
>   |     |  |        +--:(tcp-ao)
>   |     |  |        |  +--rw enable-tcp-ao?      boolean
>   |     |  |        |  +--rw ao-keychain?        key-chain:key-chain-ref
> 
> 
> draft-ietf-idr-bgp-model
> 
>          |  |  |  +--rw (option)?
>          |  |  |     +--:(ao)
>          |  |  |     |  +--rw enable-ao?             boolean
>          |  |  |     |  +--rw send-id?               uint8
>          |  |  |     |  +--rw recv-id?               uint8
>          |  |  |     |  +--rw include-tcp-options?   boolean
>          |  |  |     |  +--rw accept-ao-mismatch?    boolean
>          |  |  |     |  +--rw ao-keychain?
>          |  |  |     |          key-chain:key-chain-ref
> 
> We are not echoing the full structure because the L3NM is a network model,
> not a device model. A network model does not aim to control every
> parameter that can be manipulated at the device level. Other than
> enabling/disabling TCP-AP and providing the ao-keychain, we didn't identify a
> need to control and customize at the network service level the data nodes in
> draft-ietf-tcpm-yang-tcp:
> 
>          |  |  |     |  +--rw send-id?               uint8
>          |  |  |     |  +--rw recv-id?               uint8
>          |  |  |     |  +--rw include-tcp-options?   boolean
>          |  |  |     |  +--rw accept-ao-mismatch?    boolean
> 
> These optional nodes can be part of a local profile that can be directly
> manipulated at the device module (draft-ietf-idr-bgp-model).

It is always an interesting (and pretty fundamental) question what device parameters can indeed be abstracted in a network model. My personal (well, somewhat dated) experience is that different operators have very different preferences what parameters to include in a network model. Careful reasoning may be required for any omission of a device parameter.

In this specific case, I don't fully understand how VPN provisioning via the network level model would pick the values for "send-id" and "recv-id"? Those parameters need to be configured consistently on both endpoints of the TCP-AO connection, right? What happens if the network model draft-ietf-opsawg-l3sm-l3nm only configures one of the two TCP-AO endpoints?

So, why can "send-id" and "recv-id" be removed?

> We can make these changes, though:
> 
> s/tcp-ao/ao
> s/enable-tcp-ao/enable-ao

It certainly makes sense to use at least consistent naming in different IETF models, but unless there is a good reason to remove "send-id" and "recv-id", you could just directly import the grouping to ensure consistency...

Michael

> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Martin Duke via Datatracker [mailto:[e-mail]]
> > Envoyé : dimanche 19 septembre 2021 19:55
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Objet : Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> > DISCUSS)
> >
> > Martin Duke has entered the following ballot position for
> > draft-ietf-opsawg-l3sm-l3nm-11: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-
> > criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > (7.6.3) Is there a reason the TCP-AO model in this draft is different
> > from the one in draft-ietf-idr-bgp-model-11? That draft is using a model
> > developed in the TCPM WG (draft-ietf-tcpm-yang-tcp) specifically for
> > that purpose.
> >
> > If there is no compelling requirement for something different, or the
> > TCPM modelling work can be stretched to cover this use case as well, it
> > would be far better than rolling a totally separate TCP YANG model here.
> >
> >
> >
> >
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg