Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 - aggregate awareness

["Joel M. Halpern" <[e-mail]>]

With regard to what routers need to be aware of what, I read the wording 
you quote slightly and importantly differently.

As I understand it, that wording means that any rotuer that is providing 
different treatment to a slice flow aggregate (e.g. giving it different 
queueing or other resources) has to be aware of the slice aggregate it 
is treating and how to recognize which packets fall into that slice 
aggregate.

I believe that is the meaning of the words.  And it seems almost 
tautological.  (But still useful to say.)

Yours,
Joel

On 2/22/2022 3:40 AM, [e-mail] wrote:
> Hi all,
> 
> I highly appreciate the effort made by various author groups to edit this document. Please find below some comments, fwiw:
> 
> (1) I reviewed a previous version of the draft (https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-bestbar-teas-ns-packet-05-rev%20Med.pdf). I know that Tarek (many thanks) released an updated version after that review, but when checking the diff 05-08, I still have many of these concerns with the latest version.
> 
> (2) I have a mixed feeling when reading this document. I like the architectural parallel with 2475, but I'm less comfortable with many of the individual solutions cited in the draft. Separating the overall architecture discussion vs. solution-specific details would be my favorite approach. However, this would conflict with the scope set for the draft:
> 
>     "The focus of this document is on the
>     mechanisms required at the device level to address the requirements
>     of network slicing in packet networks."
> 
> This is even worse as the document says:
> 
>     A router MUST be able to identify a packet belonging to a Slice-Flow
>     Aggregate before it can apply the associated dataplane forwarding
>     treatment or NRP-PHB.  One or more fields within the packet MAY be
>     used as an FAS to do this.
> 
> which seems to mandate that ** every ** router in the network should be slice-aware, which is not required IMO.
> 
> Also, the parallel of an NRP vs. per-domain behavior (PDB) is worth to be mentioned.
> 
> (3) I would like if the document can be more explicit in answering questions such as: "Can we realize a slice without having to define a new data plane extension?". The answer is definitely "Yes". See for example the work documented at: https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slices-instantation-02
> 
> (4) I don't think the document should be published in the Standards Track, but Informational.
> 
> (5) I suggest to update the title form "Realizing Network Slices in IP/MPLS Networks" to "An Approach for Realizing Network Slices in IP/MPLS Networks"
> 
> (6) The document states that it " provides a path control technology ... agnostic solution .", while it includes many solution-specific details and even normative references pointing to some "path control" mechanisms.
> 
> (7) It is not clear to me what was the rationale for keeping some individual I-Ds as normative, while accepting to move some others to be informative.
> 
> (8) The document reasons about aggregating "slices" while I think the intent is "slice services". If the slices are aggregated themselves, then a state is needed to be maintained in the network about these individual slices (at least at boundary nodes to glue an individual slice and its parent aggregate). If services are aggregated, then the optimization at the boundary devices is made possible. The "aggregation" information will need to be maintained in controllers.
> 
> (9) The definition section includes some architectural assumptions, e.g.,
> 
>        the mapping of one or more IETF network slices to a
>        Slice-Flow Aggregate is maintained by the IETF Network Slice
>        Controller.
> 
> This may also be maintained by an ingress node (as per (8)).
> 
> (10) Many parts of the document can just apply to individual slices, not only aggregates. It would be helpful to call this out as appropriate.
> 
> Thank you.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Teas <[e-mail]> De la part de Lou Berger
>> Envoyé : vendredi 18 février 2022 14:28
>> À : TEAS WG <[e-mail]>
>> Cc : TEAS WG Chairs <[e-mail]>; draft-bestbar-teas-ns-
>> [e-mail]
>> Objet : [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>>
>> Hello,
>>
>> This email begins a 2-week adoption poll for:
>> https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/
>>
>> Please note that IPR has been disclosed on this document:
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-
>> teas-ns-packet
>>
>> Please voice your support or objections to adoption on the list by the
>> end of the day (any time zone) March 4.
>>
>> Thank you,
>> Lou (as Co-chair)
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas