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

["Rob Wilton (rwilton)" <[e-mail]>]

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


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

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?

> 
>  and it isn't obvious
> > that it is actually either of those.  I.e., really it is just a
> > parent to sub-interfaces that represent the VPLS and L3VPN SAPs.
> 
> [Med] These SAPs fall under:
> 
>       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.
> 
> >
> > Hence, I was asking whether you considered putting GE0/6/1 into a
> > different service/sap list (e.g., of service-type "sap-parent"),
> > or similar.  This would mean that the interface would be listed
> > only once rather than under both VPLS and L3VPN.
> 
> [Med] We are listing them per service because some interfaces may be
> restricted to specific services. In the example, it happen that this interface is
> ready to hots both VPLS/L3VPN, but there might be cases where a "parent"
> SAP will listed only for a single service.

Okay.


> 
> >
> >
> > >
> > >   Related to this, it
> > > > feels slightly strange to me to have GE0/6/4 listed under both
> > l3vpn
> > > > and vpls SAP lists.
> > >
> > > [Med] Actually there are attached to distinct sub-interfaces:
> >
> > So, my question is really whether, in this case, GE0/6/4 is
> > actually a SAP at all, or whether really it is only the child sub-
> > interfaces of GE0/6/4 that are actually SAPs?
> 
> [Med] It is a special SAP. We need to have it listed as such because otherwise
> we can't display where a service can be delivered unless a child SAP is
> explicitly instantiated.
> 
> >
> > Possibly adding the "ready-child-sap" resolves this ambiguity.
> 
> [Med] Agree.
> 
> > Possibly, I would have a chosen a different name and description
> > for this leaf (e.g., "sap-parent") that indicates that this node
> > can act as a parent to other SAPs.
> >
> >
> > >
> > >    Also, let us assume that, for
> > >    the SAPs that are associated with the physical interface
> > "GE0/6/4",
> > >    VPLS and L3VPN services are activated on the two sub-
> > interfaces
> > >    "GE0/6/4.1" and "GE0/6/4.2", respectively.
> > >
> > > Updated the example to align with this text.
> > >
> > >   Having the same information twice in
> > > > the data model introduces the risk that a device could export
> > > > inconsistent information and hence it hard for the customer to
> > know
> > > > which data is accurate.  I can understand why having it twice
> > might
> > > > be convenient, but having an indication that it is actually
> > just a
> > > > container node for SAPs rather than a SAP itself might be
> > better.
> > > >
> > > >
> > > >
> > > > Minor level comments:
> > > >
> > >
> > > >
> > > > (5) p 10, sec 5.  SAP Module Tree Structure
> > > >
> > > >    These service types build on the types that are already
> > defined
> > > > in
> > > >    [RFC9181] and additional types that are defined in this
> > document.
> > > >    Other service types can be defined in future YANG modules,
> > if
> > > > needed.
> > > >
> > > > In future YANG modules, or perhaps also future versions of the
> > YANG
> > > > model defined in this document?
> > > >
> > >
> > > [Med] Changed to "future YANG modules (including future
> > revisions of
> > > the YANG model defined in this document)"
> >
> > Okay.
> >
> > >
> > > >
> 
> >
> > >
> > >
> > > > (9) p 17, sec 6.  SAP YANG Module
> > > >
> > > >          leaf peer-sap-id {
> > > >            type string;
> > > >            description
> > > >              "Indicates an identifier of the peer's
> > termination
> > > >               identifier (e.g., Customer Edge (CE)). This
> > > >               information can be used for correlation
> > purposes,
> > > >               such as identifying the SAP that is attached to
> > > >               an endpoint that is provided in a service
> > request.";
> > > >          }
> > > >
> > > > Would it be helpful to indicate that the "peer-sap-id" is not
> > > > necessarily the same as the peer's sap_id for that same
> > attachment
> > > > circuit endpoint?  E.g., it appears to differ in your example
> > in
> > > > Appendix C.
> > > >
> > >
> > > [Med] Given that this is used for correlation purposes, the
> > value
> > > enclosed in peer-sap-id is useful when it is known to the peer.
> > > Typically, that value will be indicated as the service delivery
> > point. I tend to leave the description as it is.
> >
> > Okay, the reason that I queried this was that in your appendix C,
> > you don't appear to follow this.  E.g., the peer_sap_id for
> > "sap#12" is given as "asbr-b1", but that is probably not what the
> > peer sap id would actually be (or otherwise all the "peer_sap_id"
> > names would collide).  Perhaps this example is an exception to the
> > rule, but then that would be worth highlighting in the text that
> > describes the example.
> >
> >
> 
> [Med] Fair. I added the following:
> 
> " This identifier may or may not be the same as the SAP identifier used in the
> peer's configuration. Note that the use of identical identifiers eases
> correlation between a peer's service request with a local SAP. "

Looks good.  Thanks.

Regards,
Rob