Re: [Teas] Mail regarding draft-ietf-idr-flowspec-network-slice-ts

[[e-mail]]

Hi Jie,

Please see inline.

Cheers,
Med

De : Dongjie (Jimmy) <[e-mail]>
Envoyé : jeudi 27 avril 2023 11:19
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Cc : TEAS WG ([e-mail]) <[e-mail]>
Objet : RE: Mail regarding draft-ietf-idr-flowspec-network-slice-ts

Hi Med,

Thanks for your further comments. Please see inline:

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Tuesday, April 25, 2023 10:53 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: RE: Mail regarding draft-ietf-idr-flowspec-network-slice-ts

Hi Jie,

Thanks for the follow-up. I don't think I misunderstood the mechanisms in the draft.

Take for example this text:

   To meet the connectivity and performance requirements of
   network slice services, network slice service traffic needs to be
   mapped to a corresponding Network Resource Partition (NRP).

This text should be adjusted as there is not always more than one NRP. This can be simply fixed: s/needs/may need.

[Jie] This text does not say that there is always more than one NRP. But it is OK to make the change as you suggested.
[Med] Thanks.

As another example, let's consider this text:


   The edge nodes of an NRP needs to identify the traffic

   which belong a network slice and steer the matched packets into the

   corresponding NRP, so that the packet can be forwarded via either a

   shortest path or a Traffic Engineering (TE) path within the NRP.

Or


   For data packets which match the flow specification of a network

   slice, specific forwarding actions need to be applied.  When the

   network slice service flows are mapped to an NRP in the underlay

   network, the packets of the flows need to be forwarded in the

   corresponding NRP using either a shortest (BE) path or a Traffic

   Engineering (TE) path.


This is clearly not aligned with this part from the framework:

   One or more connectivity constructs from one or more IETF Network
   Slices are mapped to an NRP.  A single connectivity construct is
   mapped to only one NRP (that is, the relationship is many to one).

[Jie] The text is about matching and steering traffic of network slices into the corresponding NRP.
[Med] "..corresponding NRP" wording suggested that there will be one and only one NRP mapping per slice.

I guess you mean it should be "match and steer the traffic of specific connectivity constructs of the network slices to the corresponding NRP"?
[Med] Yes, that's better.

Since Flowspec can provide flexible matching and steering rules for traffic flows of one or multiple connectivity constructs in the network slices, we didn't mention such detail for simplicity.
[Med] Absent these details, I think that what the document does is NRP steering (that can be used without slicing).

But if you think this needs clarification, we could make that change also.
[Med] Thanks

Etc.

BTW:


         Global bit (g): When set, it indicates the NRP ID to be matched

         is a global unique NRP ID; otherwise the NRP ID is a domain

         significant NRP ID.

How this is bit is used?

[Jie] As described in the draft, the g bit is used to indicate whether the NRP ID is a multi-domain global unique ID, or a domain significant ID. Basically this would impact the matching policy and the actions to be performed at the domain edge nodes. We will add further text in next version.
[Med] I sill don't see how this can influence the policies, but I trust you will include more detail to explain the intended usage. Thanks.

Best regards,
Jie

Thank you.

Cheers,
Med

De : Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 18 avril 2023 17:53
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Objet : RE: Mail regarding draft-ietf-idr-flowspec-network-slice-ts

Hi Med,

Thanks for your review and comments on this document. You may misunderstand the mechanisms described in this draft a little, so let me try to clarify.


The purpose of the proposed mechanism is to use BGP Flowspec to distribute the rules for matching some fields of the network slice service packets at the network ingress nodes, then the matched packets could be steered into the corresponding NRP.  Thus it is about steering network slice services into NRPs, and optionally specific TE paths of the NRPs. It does not infer any limitation about whether multiple network slices services are mapped to the same or different NRPs. As you said that is all based on deployment policy.



As mentioned in the draft, the existing Flowspec components can be reused for the matching of network slice services at the edge of an NRP, so the matching is not just based on the NRP ID. Actually the NRP ID component is only introduced for some specific cases (e.g. the domain edge nodes of multi-domain NRPs) for packet matching. We will clarify that in next revision.


Best regards,
Jie

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 18, 2023 1:47 PM
To: [e-mail]<mailto:[e-mail]>
Cc: TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Mail regarding draft-ietf-idr-flowspec-network-slice-ts

Hi Authors,

The proposal in the draft is not actually about slice steering, but NRP steering. An NRP can be shared between multiple connectivity constructs of the same or distinct slices. Likewise, there is no assumption that all CCs of a slice will be mapped to the same NRP. Also, when the same NRP is used for more than one slice, distinct forwarding paths (and thus distinct actions) may be selected for each slice that shares the NRP. The NRP-ID alone is not sufficient to disambiguate slice traffic. Whether an NRP maps to one and only one slice is deployment-specific.

I think the current text in the draft is misleading. I suggest you revise the draft to better articulate the intent and capture the differences between the concept of slice vs. nrp. Thanks.

BTW, how the global bit is used?

Thanks.

Cheers,
Med

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.