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

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

Hi Qin,

I believe that in the specific case of "send-id" and "recv-id", the actual issue is that L3NM references to the RFC 8177 model that could theoretically include the required information. But RFC 8177 may have a gap there.

And since these values must be set consistently with the router a PE connects to, IMHO a default value or template for determining the device configuration may not work. As I have already said, for a lot of _other_ device configuration I can see how templates or the like would fill device configuration gaps in an abstract network model.

But for TCP-AO "send-id" and "recv-id", I think the L3NM document needs to explain where the actual values provisioned to each PE would come from. I don't understand how the PE could guess the correct value.

Granted, TCP-AO may be a minor detail of the overall L3NM model - but this kind of detail may be sort of a litmus test for how well network-level abstractions actually work.

Michael



> -----Original Message-----
> From: Qin Wu <[e-mail]>
> Sent: Thursday, September 23, 2021 11:05 AM
> To: Scharf, Michael <[e-mail]>;
> [e-mail]; Martin Duke
> <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; opsawg-
> [e-mail]
> Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS)
> 
> Hi, Michael, Med and all:
> I tend to agree with Med we should have a clear distinction between device
> level configuration and network level abstraction.
> Device level configuration will provide complete set of TCP AO properties
> configuration to make TCP AO functionality work while network level
> abstraction should focus on
> network layers configuration **across multiple devices **or **specifying
> which functionality need to be invoked**. Sometimes it is hard to find the
> clear boundary, or debatable to have or not have some parameters. But If
> we propose to add send-id and recv-id to L3NM, I am arguing why not add
> MAC algorithm, KDF, why not add other TCP connection parameters? If we
> look for adding complete set of TCP AO configuration in the draft-ietf-tcpm-
> yang-tcp, I think maybe meta model defined in draft-ietf-rtgwg-device-
> model is a better choice.
> 
> -Qin
> -----邮件原件-----
> 发件人: OPSAWG [mailto:[e-mail]] 代表 Scharf, Michael
> 发送时间: 2021年9月22日 23:38
> 收件人: [e-mail]; Martin Duke
> <[e-mail]>; The IESG <[e-mail]>
> 抄送: [e-mail]; [e-mail]; opsawg-
> [e-mail]
> 主题: Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-
> 11: (with DISCUSS)
> 
> Hi Med,
> 
> Thanks for the useful references. More inline.
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Tuesday, September 21, 2021 2:56 PM
> > To: Scharf, Michael <[e-mail]>; Martin Duke
> > <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; opsawg-
> > [e-mail]
> > Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > (with
> > DISCUSS)
> >
> > Hi Michael,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Scharf, Michael [mailto:[e-mail]]
> > > Envoyé : lundi 20 septembre 2021 12:05 À : BOUCADAIR Mohamed
> > > INNOV/NET
> > <[e-mail]>; Martin
> > > Duke <[e-mail]>; The IESG <[e-mail]> Cc :
> > > [e-mail]; [e-mail]; opsawg-
> > > [e-mail] Objet : RE: Martin Duke's Discuss on
> > > draft-ietf-opsawg-l3sm-l3nm-11:
> > > (with DISCUSS)
> > >
> > > Hi Med,
> > >
> > > What happens if PEs and CEs are both under operator control? In that
> > > case, the customer-facing L3SM model may not need any TCP-AO
> > > configuration.
> > >
> > > However, in that case, TCP-AO may need to be configured on the PEs
> > > and the "send-id" and "receive-id" values must be consistent with
> > > the CEs, no?
> >
> > [[Med]] Agree.
> >
> >  If the PE configuration is done by L3NM, the "send-id" and "receive-
> > > id" must be part of L3NM model, no?
> >
> > [[Med]] Not necessarily. See below.
> >
> >  If not, how would the TCP-AO
> > > provisioning on CEs and PEs work?
> >
> > [[Med]] The assumption we had for this version of the module is that
> > send-id and recv-id are pre-configured while only the key reference is
> > manipulated in the L3NM. Some of the implementations separate the
> > TCP-AO configuration from the invocation in context of a particular
> > protocol, e.g.,
> >
> > *
> >
> https://www.juniper.net/documentation/en_US/junos/topics/reference/g
> > eneral/release-notes/20.3/infocus-topicmaps/tcp-authentication-option-
> > map-infocus.html
> > * https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/72x/b-bgp-
> > cg-ncs5500-72x/implementing-master-key-tuple-
> > configuration.html#id_77361
> 
> Good references. As far as I can see, in those two cases the send-id and recv-
> id are modelled in the key-chain and therefore configurable as part of the
> key-chain. With such a key-chain, your assumption would work.
> 
> However, draft-ietf-opsawg-l3sm-l3nm-11 references to the key-chain from
> RFC 8177. Unlike in those two previous examples, I don't understand how
> one would encode send-id and recv-id in the RFC 8177 model.
> 
> So, my reading is that draft-ietf-opsawg-l3sm-l3nm-11 assumes that the
> referenced key-chain includes additional entries beyond RFC 8177, such as
> send-id and recv-id.
> 
> If that assumption is correct, IMHO the document draft-ietf-opsawg-l3sm-
> l3nm has to highlight that additions to the key-chain model beyond RFC 8177
> may be required for TCP-AO to work.
> 
> > We can add a note about it you think this helps. Thank you.
> 
> If the document assumes additions to RFC 8177, this must be noted, IMHO.
> 
> Of course, an alternative would be just to import draft-ietf-tcpm-yang-tcp,
> which models the relevant entries, but that will be your call.
> 
> Michael
> 
> >
> > >
> > > In a nutshell, I don't understand the argument "send-id and
> > > receive-id are not needed in L3NM because they are not included in
> > > L3SM". Also, that generic argument would apply to _a lot_ of network
> > > level configuration that is not part of L3SM.
> > >
> > > BTW, I agree that augmentation will be important for many
> > > parameters, but IMHO you have to ensure that the L3NM model includes
> > > all base parameters that are required for connectivity. At least for
> > > TCP-AO, I don't understand your specific choice in L3NM so far.
> > >
> > > Best regards
> > >
> > > Michael
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> <[e-mail]>
> > > > Sent: Monday, September 20, 2021 11:42 AM
> > > > To: Scharf, Michael <[e-mail]>; Martin Duke
> > > > <[e-mail]>; The IESG <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]; opsawg-
> > > > [e-mail]
> > > > Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > > > (with
> > > > DISCUSS)
> > > >
> > > > Hi Michael,
> > > >
> > > > The L3NM focuses on the network side (that is, PEs). The module is
> > > > typically triggered by an L3SM (where the values may be agreed
> > > > with a
> > > customer).
> > > > FYI, the L3SM (RFC8299) does not support the capability to
> > > > customize
> > > > TCP- AO.
> > > >
> > > > When the L3SM (RFC8299) is augmented in the future to support
> > > > send-id and recv-id, then the L3NM can be easily augmented to pass
> > > > them to
> > > PEs.
> > > >
> > > > What is really important is that we have a provision for such
> > > > augment to happen.
> > > >
> > > > Thank you.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Scharf, Michael [mailto:[e-mail]]
> > > > > Envoyé : lundi 20 septembre 2021 11:10 À : BOUCADAIR Mohamed
> > > > > INNOV/NET
> > > > <[e-mail]>; Martin
> > > > > Duke <[e-mail]>; The IESG <[e-mail]> Cc :
> > > > > [e-mail]; [e-mail]; opsawg-
> > > > > [e-mail] Objet : RE: Martin Duke's Discuss on
> > > > > draft-ietf-opsawg-l3sm-l3nm-11:
> > > > > (with DISCUSS)
> > > > >
> > > > > 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