Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09

[[e-mail]]

Hi Rob, 

Thanks for the follow-up. 

Made some changes to hopefully fix the pending points: https://tinyurl.com/sap-latest. Also, added a NEW para to exemplify how controllers of each AS are using the model to provision inter-as VPN option A. This is to address a comment we received from an implementer.  

Please see inline for more context.

Will wait for your ACK before submitting the new version. 

Cheers,
Med

> -----Message d'origine-----
> De : Rob Wilton (rwilton) <[e-mail]>
> Envoyé : dimanche 6 novembre 2022 16:50
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; draft-
> [e-mail]; [e-mail]
> Objet : RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Med,
> 
> Apologies for the delay.  The behaviour is still not entirely clear to
> me.  Please see inline ...
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: 29 September 2022 15:18
> > To: Rob Wilton (rwilton) <[e-mail]>; draft-ietf-opsawg-
> > [e-mail]; [e-mail]
> > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Rob,
> >
> > Thanks for the follow-up.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Rob Wilton (rwilton) <[e-mail]> Envoyé : jeudi 29
> > > septembre 2022 15:24 À : BOUCADAIR Mohamed INNOV/NET
> > <[e-mail]>;
> > > [e-mail]; [e-mail] Objet : RE: AD
> > > review of draft-ietf-opsawg-sap-09
> > >
> > > Hi Med,
> > >
> > > Comments inline below ...
> > >
> > > I've snipped out anything that we have already reached agreement
> on.
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > <[e-mail]>
> > > > Sent: 23 September 2022 14:04
> > > > To: Rob Wilton (rwilton) <[e-mail]>; draft-ietf-opsawg-
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> > > >
> > > > Hi Rob,
> > > >
> > > > Thank you for the review. The changes can be tracked at:
> > > > https://tinyurl.com/sap-latest
> > > >
> > > > Please note that I made a change to better allow for reuse of
> > > the SAP
> > > > information in other modules (this can be tracked here:
> > > > https://github.com/IETF-OPSAWG-
> > > > WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).
> > >
> > > Okay.
> > >
> > >
> > > >
> > > > Please see inline for more context.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Rob Wilton (rwilton) <[e-mail]> Envoyé :
> > > vendredi 23
> > > > > septembre 2022 14:01 À : [e-mail];
> > > > > [e-mail] Objet : AD review of draft-ietf-opsawg-sap-09
> > > > >
> > > > > Hi authors, WG,
> > > > >
> > > > > Thank you for this document.  I also think that this document
> > > is
> > > > > well written and in good shape, and I mostly found the
> > > explanations
> > > > > and examples clear.  There were two specific points that I
> > > found
> > > > > slightly confusing related to differentiating between SAPs in
> > > use,
> > > > > and those that are not, and also parent interfaces also be
> > > listed as
> > > > > SAPs, details below.
> > > >
> > > > [Med] Thanks
> > > >
> > > > >
> > > > > Moderate level comments:
> > > > >
> > > > > (1) p 10, sec 5.  SAP Module Tree Structure
> > > > >
> > > > >       SAPs that are associated with the interfaces that are
> > > directly
> > > > >       hosting services, interfaces that are ready to host per-
> > > > > service
> > > > >       sub-interfaces (but not yet activated), or service that
> > > are
> > > > >       already instantiated on sub-interfaces are listed as
> > > SAPs.
> > > > >
> > > > > >From the model, is isn't clear to me how different
> > > differentiates
> > > > > between a SAP that has been pre-provisioned to potentially be
> > > used
> > > > > for a service in future, v.s., one is that is actively
> > > provisioned.
> > > >
> > > > [Med] This is inferred from the service-status=down for these
> > > SAPs.
> > >
> > > So, thinking of this at device level configuration there is
> > > effectively 3 levels of configuration/activation (at least for
> > > L2VPNs):
> > >
> > > (1) A sub-interface is configured, but without any IP address or
> > > VRF (for L3VPN), or without being attached to an L2VPN or Bridge
> > > Domain (for L2VPNs).  I.e., the sub-interface isn't connected
> > > anyway.
> > > (2) The sub-interface is configured and connected into a bridge
> > > domain or P2P L2VPN but that service is down (e.g., perhaps
> > > because the AC at the remote end of the L2VPN is physically down).
> > > (3) The sub-interface is configured and connected into a bridge
> > > domain or P2P L2VPN and that service is up.
> > >
> > > I think that you are saying that you regard that both (1) and (2)
> > > would be indicated by service-status=down?  Would it be worth
> > > expanding the description at all to make this more explicit?
> >
> > [Med] The implicit model has some limitations, indeed. Glad to see
> that we
> > reached the same conclusion. Please see this note I sent early this
> week:
> >
> https://mailarchive.ietf.org/arch/msg/opsawg/C_aI8qsGbdUif9Ems8bN0s3E
> > kj4/
> >
> >
> >  But
> > > I'm still not convinced this will be sufficient (e.g., see my
> > > following response below related to the example for selecting a
> > > service).
> > >
> > > >
> > > >
> > > >   I think that it would be helpful if these two cases
> > > > > can be clearly distinguished.  Note, I have made a similar
> > > comment
> > > > > related to appendix D about identifying a "free" SAP.
> > > >
> > > > [Med] Added this NEW to the appendix:
> > > >
> > > > "SAPs that are ready to host per-service (but not yet activated)
> > > are
> > > > identified by the "service-status" set to "ietf-vpn-common:op-
> > > down"."
> > >
> > > But how do you distinguish between a SAP that hasn't been
> > > provisioned yet to a service vs a SAP that has been provisioned
> > > but the service is down?  E.g., trying to find a free SAP just by
> > > looking for a SAP with a service-status of op-down doesn't appear
> > > to be sufficient on its own.
> >
> > [Med] A SAP that is not provisioned yet will have a sap-status=down,
> while
> > the one that is provision but the service is not activated will have
> sap-
> > status=up and service-status=down. Isn't that sufficient?
> 
> I would have assumed:
>  - If sap-status is down then the service-status must also be down,
> right?

[Med] Actually, no. The service status indicates whether a service is associated with the SAP. Added both the admin and op status of the service status and added this NEW text: 

"This data node indicates whether a service is bound to this SAP and, as such, it is not influenced by the value of the 'sap-status'."

>  - if the sap is a sub-interface and the parent interface is down,
> then the sap-status would also be down?
> 
> Hence, I would have thought that you cannot distinguish between it not
> being provisioned and it is provisioned but the SAP is down either due
> to the parent, or perhaps the sub-interface has explicitly been forced
> down for some reason (perhaps due to config, or other reasons).
> 
> Perhaps you are saying that this isn't a problem in practice?
>

[Med] I think that having an admin status to explicitly indicate whether a service is activated for a SAP makes the checks to find a free SAP more easier. 
 
> 
> >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > (2) p 28, sec Appendix B.  A Simple Example of SAP Network
> > > Model:
> > > > > Node Filter
> > > > >
> > > >
> > > > [Med] Please note "Simple" in the title :-)
> > >
> > > OK, noted. ;-)
> > >
> > >
> > > >
> > > > >    A service orchestrator can query what services are provided
> > > on
> > > > > which
> > > > >    SAPs of PE1 from the network controller by sending, e.g., a
> > > GET
> > > > >    RESTCONF request.  Figure 9 shows the body of the RESTCONF
> > > > > response
> > > > >    that is received from the network controller.
> > > > >
> > > > > In this example, you have GE0/6/4 as being ready to host SAPs,
> > > but I
> > > > > could equally imagine that given GE0/6/4 is just a UNI, then
> > > you may
> > > > > not want the parent interface to be available to host SAPs
> > > directly
> > > > > at all.  I.e., it may always the case that sub-interfaces are
> > > used
> > > > > as SAPs.  Hence, did you consider whether it makes sense for
> > > there
> > > > > to be a different category of SAP service-types for UNI's and
> > > NNI's
> > > > > that don't host services directly on the interface, but always
> > > on
> > > > > sub-interfaces?
> > > >
> > > > [Med] Yes, we do need this for the LxVPN case.
> > >
> > > It's still not clear to me.  E.g., in the example, GE0/6/4 is
> > > listed as an VPLS SAP and as an L3VPN SAP,
> >
> > [Med] I see. That SAP is a special one as it tags an interface that
> is ready to
> > host per-service sub-interfaces. This is now clearly indicated by
> the new leaf
> > "ready-child-sap". This is some kind of root or parent SAP.
> 
> Okay.
> 
> So, does "ready-child-sap" mean that the interface itself cannot be
> directly bound to a service, and only the child SAPs can be?  Or does
> it mean that a service could be bound both to the sap itself, and also
> as child SAPs?  Either way, I think that it would be helpful for that
> to be documented/clarified.
> 

Med: Added a note that basically says that this depends on the service. For example, a slice service can be bound to the parent and/or the childs.

> I still not a big fan of the name "ready-child-sap", because it seems
> to describe a point of time rather that what it is.  Would something
> like "allows-child-saps" or "child-sap-capable" be clearer?
> 

Med: Went for "allows-child-saps" 



_________________________________________________________________________________________________________________________

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.