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

[Adrian Farrel <[e-mail]>]

I have a fly-by response to this which is to say that "service degraded" is not the same as "service down".

Consider a p2mp service where one leaf is suddenly not reachable. You might say that the contracted service is not being delivered, but it will often be "almost completely" being delivered. It is degraded but failed.

Similarly, an L3VPN service where a site becomes unreachable.

Thus SAP failure does not always imply service failure.

Adrian

On 06/11/2022 16:50 Rob Wilton (rwilton) <[e-mail]> wrote:

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" rel="noopener nofollow" target="_blank">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-" rel="noopener nofollow" target="_blank">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" rel="noopener nofollow" target="_blank">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 be down? Hence, interface is down, then the sap-status would also  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