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

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

> -----Original Message-----
> From: Qin Wu <[e-mail]>
> Sent: Thursday, September 23, 2021 1:25 PM
> 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)
> 
> I assume many of us don't understand the difference between device model
> and network model, how network model is mapped down to device level
> models.
> See figure 5 of RFC8969, In order to deliver L3VPN service, the L3NM defined
> configuration or abstraction should be further decomposed into a set of
> detailed configuration parameters of device model such as BGP, Network
> Instance, QoS, key chain, etc
> which specify detailed protocol specific parameters such as BGP or feature
> specific parameters such as key chain.

The challenge is that the key chain model referenced by draft-ietf-opsawg-l3sm-l3nm may not contain the two parameters needed for TCP-AO.

IMHO we are here not discussing model mapping in general, but how to ensure that TCP-AO can work with the specific key chain model referenced in draft-ietf-opsawg-l3sm-l3nm.

> TCP-AO will be part of BGP configuration parameters. L3NM focus on specify
> which functionality needs to be invoked such as TCP-AO, BGP model will
> document details of configuration parameters which include TCP-AO.

L3NM models quite a bit of the detailed BGP configuration already. So, one may wonder why a subset of relevant BGP parameters is included in L3NM, but two other TCP-AO-related parameters that also have to be configured are omitted in the L3NM model, or in the key-chain it uses.

And these two TCP-AO parameters are specifically relevant since these two identifiers may need to be set consistently with the BGP neighbor, i.e., templates or other forms of auto-provisioning may not work - unless I miss something.

> Another choice is L3NM defined configuration will be decomposed into
> [e-mail] defined in draft-ietf-rtgwg-
> device-model, details of configuration related to TCP-AO will be specified in
> the [e-mail].
> Therefore you can see different vendors may come up with different
> mapping solution or decomposition.

My understanding is that we don't discuss device models and mapping to vendor-specific models in this thread. 

Michael


> Hope this clarifies.
> 
> -Qin
> -----邮件原件-----
> 发件人: Scharf, Michael [mailto:[e-mail]]
> 发送时间: 2021年9月23日 17:42
> 收件人: Qin Wu <[e-mail]>;
> [e-mail]; Martin Duke
> <[e-mail]>; The IESG <[e-mail]>
> 抄送: [e-mail]; [e-mail]; opsawg-
> [e-mail]
> 主题: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS)
> 
> 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-optio
> > > n-
> > > 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-l3
> > > > > > > > nm
> > > > > > > > /
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ----------------------------------------------------------
> > > > > > > > --
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > 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