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

[[e-mail]]

Hi Joel, 

I fully agree that if the text said "A router that is providing different treatment to a slice flow aggregate ...." that would be tautological and I would be less concerned with it.

What I was concerned with is to require more service context that isn't required for normal operation of a data plane solution. Think about a domain in which slice aggregates are bound to diffserv PDBs. Routers do not need to be aware that a PHB is for a specific service (slice service, in this case); they will just apply the corresponding treatment to the traffic as appropriate. 

Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[e-mail]> De la part de Joel M. Halpern
> Envoyé : mardi 22 février 2022 17:28
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; TEAS WG
> <[e-mail]>
> Objet : Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 -
> aggregate awareness
> 
> 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-slice
> > s-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-bestba
> >> r-
> >> 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.