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

[[e-mail]]

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.

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


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?

Thank you.

Cheers,
Med

De : Dongjie (Jimmy) <[e-mail]>
Envoyé : mardi 18 avril 2023 17:53
À : 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 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.