Re: [Teas] Review of draft-ietf-teas-5g-ns-ip-mpls

[Krzysztof Szarkowicz <[e-mail]>]

Hi Reudiger,


Thank you for your comments.

We will be looking for RFC8100 in upcoming revision of the draft.


Regards,
Krzysztof

On 2023 -Oct-30, at 17:12, [e-mail]<mailto:[e-mail]> wrote:

Hi Med,

Thanks, I’ve read a bit more context and understand, that “transport” related terminology mostly/entirely relates to “transport network” and linked concepts in your draft. Please ignore my comment related to Chapter 6.

Regards,

Ruediger



Von: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Gesendet: Montag, 30. Oktober 2023 14:32
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: RE: Review of draft-ietf-teas-5g-ns-ip-mpls

Hi Ruediger,

Thank you for the comments.

Good to hear that you have no issue with the DSCP mapping approach. Please see inline.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 30 octobre 2023 10:47
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : AW: Review of draft-ietf-teas-5g-ns-ip-mpls

Hi Med,

thanks for forwarding your draft.

My focus is backbone QoS and I appreciate your approach decoupling “inner” and “outer” QoS treatment, assuming bulk traffic QoS treatment at the outer header. I got no issue with your per DSCP mapping approach.

If you’d like to mention additional options, RFC 8100 offers an option aggregating DSCPs based on the 3 most significant DSCP bits, creating 8 DSCP ranges for classification. Please note, that also https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-20#name-aggregation-of-other-dscps- specifies mapping of DSCPs to PHBs by evaluating the three most significant DSCP bits only, and that latter draft is standards track. The method proposed by both docs allows to assign 8 DSCPs sharing the same 3 most significant bits on 8 “inner”/slice QoS-classes and simply map them to one outer/network 3-bit codepoint  by one policy entry rather than one per DSCP. I look at that as one further option and suggest to amend the method to your existing text, but whether or not you do that, I leave to you.

[Med] Thanks for the pointers. I’m familiar with 8100, so I see how to cite it. I added an issue to record this (https://github.com/boucadair/5g-slice-realization/issues/71).

Chapter 6 https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-ns-ip-mpls-01#name-transport-planes-mapping-mo: To me the transport-planes you mention there sound like “SR Policy” options. If you and the author team agree, you might remove “transport” from chapter 6 terminology and replace it by something like “SR-Policy based routing” . I hope, the concept you address in your chapter 6 is specified by https://datatracker.ietf.org/doc/html/rfc9256 in general, as “SR Policy”.

[Med] A transport plane may be realized with an SR policy but there are out there a variety means that are not SR-specific. For example, we do have a similar concept already in RFC9181/RFC9182/RFC9291 called “underlay-transport”, which is basically about TE-tweaking of the connectivity between PEs to accommodate a set of performance objectives.


RFC8402, https://datatracker.ietf.org/doc/html/rfc8402#section-1:

A node individually decides to steer packets on an SR Policy (...).  A node individually computes the SR Policy.


Regards,

Ruediger



Von: tsvwg <[e-mail]<mailto:[e-mail]>> Im Auftrag von [e-mail]<mailto:[e-mail]>
Gesendet: Freitag, 27. Oktober 2023 14:06
An: Gorry Fairhurst <[e-mail]<mailto:[e-mail]>> ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Betreff: [tsvwg] Review of draft-ietf-teas-5g-ns-ip-mpls

Hi Gorry & TSVWG,

TEAS WG is currently working on this specification: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/.

We would appreciate any feedback you may provide on the document, especially on the following parts:

==
5.  QoS Mapping Realization Models
5.1.  QoS Layers
5.1.1.  5G QoS Layer
5.1.2.  TN QoS Layer
5.2.  QoS Realization Models
5.2.1.  5QI-unaware Model
5.2.2.  5QI-aware Model
5.3.  Transit Resource Control
6.  Transport Planes Mapping Models
6.1.  5QI-unaware Model
6.2.  5QI-aware Model
==

We know that the “transport” terminology thing may hurt many (we are also not comfortable with it). However, we decided to use a terminology that is well-established for the intended “consumers” of the spec. The “Transport Network” is defined by the 3GPP as the "part supporting connectivity within and between CN and RAN parts" (Section 1 of TS-28.530).

Thank you.

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.

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas