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

[[e-mail]]

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_aI8qsGbdUif9Ems8bN0s3Ekj4/ 


 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? 

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

 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. 

> 
> 
> >
> >   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.
> 
> >
> > >
> > > (6) p 11, sec 5.  SAP Module Tree Structure
> > >
> > >       This data node can be used, for example, to decide
> whether an
> > >       existing SAP can be (re)used to host a service or if a
> new
> > > sub-
> > >       interface has to be instantiated.
> > >
> > > So, is this field effectively also being used to determine if
> the
> > > SAP is in use?
> > >
> >
> > [Med] No, this is determined by 'sap-status' (completed with
> 'service-
> > status').
> >
> >
> > >
> > > (7) p 12, sec 5.  SAP Module Tree Structure
> > >
> > >       When both a sub-interface and its parent interface are
> > > present,
> > >       the status of the parent interface takes precedence over
> the
> > >       status indicated for the sub-interface.
> > >
> > > This seems strange to me.  E.g., if the parent-interface was
> up, but
> > > the sub-interface was administratively down then would you be
> > > expected to report the sap-status as up?  I would think that
> this
> > > should always be reporting the sub-interface state, but that
> the
> > > sub-interface state should inherit
> > >
> >
> > [Med] Good catch. "but the parent interface is disabled" was
> missing
> > from the OLD text.
> 
> Okay.
> 
> 
> >
> > >
> > > (8) p 16, sec 6.  SAP YANG Module
> > >
> > >      identity logical {
> > >        base interface-type;
> > >        description
> > >          "Refers to a logical sub-interface that is typically
> > >           used to bind a service. This type is used only
> > >           if none of the other logical types can be used.";
> > >      }
> > >
> > > Perhaps clarify what you mean by "other logical types".  E.g.,
> do
> > > you just mean loopback or irb, or does this include local-
> bridge as
> > > well?
> > >
> > >
> >
> > [Med] We meant the other non-PHY types already defined. Changed
> to:
> >
> >       "Refers to a logical sub-interface that is typically
> >        used to bind a service. This type is used only
> >        if none of the other types (i.e., loopback, lag,
> >        irb, or local-bridge) can be used.";
> 
> Okay.  As a minor suggestion, you could possibly change "types" to
> "other more specific types".
> 

[Med] That's better. Thanks. 

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

> 
> >
> > >
> > > (10) p 19, sec 8.  Security Considerations
> > >
> > >    *  /nw:networks/nw:network/nw:node/sap:service-type/sap:sap
> > >
> > > Should this be:
> > > /nw:networks/nw:network/nw:node/sap:service/sap:sap ?
> > >
> >
> > [Med] This should be
> > "/nw:networks/nw:network/nw:node/sap:service/sap:service-
> > type/sap:sap"
> 
> According to the tree diagram, I don't think this path can be
> right because service-type is a terminal leaf node. I.e., "sap" is
> augmented onto "service" not "service-type".
> 
> 

[Med] Indeed.  

> 
> >
> > >
> > > (11) p 20, sec 8.  Security Considerations
> > >
> > >    *  /nw:networks/nw:network/nw:node/sap:service-type/sap:sap
> > >
> > > Should this be:
> > > /nw:networks/nw:network/nw:node/sap:service/sap:sap ?
> 
> This will need to be similarly fixed (if we agree).

[Med] ACK.

> 
> 
> > >
> > >
> > > (12) p 25, sec Appendix A.  A Simplified SAP Network Example
> > >
> > >    An example of a SAP topology that is reported by a network
> > > controller
> > >    is depicted in Figure 7.  This example echoes the topology
> shown
> > > in
> > >    Figure 4.  Only a minimum set of information is provided
> for each
> > >    SAP.
> > >
> > > I'm surprised that service-status isn't reported for the saps
> that
> > > only have names.  Perhaps that information is elided to make
> the
> > > examples shorter, but it may be helpful to clarify that.
> E.g.,
> > > perhaps expand "Only a minimum set of information is provided
> for
> > > each
> > >    SAP." to be explicit about SAP information that has been
> elided
> > > (e.g., attachment interface, interface type, role).  Or
> perhaps a
> > > bit more of an explanation about how different SAPS are being
> > > modelled here would be helpful
> >
> > [Med] That was the intent of having "Only a minimum set of
> information
> > is provided for each SAP.", but I hear this is no that clear.
> Added
> > the status and a mention about the nodes that are listed for the
> sake of illustration.
> 
> Thanks.  The updated text that you have in your latest looks
> better.
> 
> Thanks,
> Rob


_________________________________________________________________________________________________________________________

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.