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

[Tarek Saad <[e-mail]>]

Hi Zhibo,

See inline.

From: Teas <[e-mail]> on behalf of Huzhibo <huzhibo=[e-mail]>
Date: Friday, February 25, 2022 at 8:03 PM
To: Vishnu Pavan Beeram <[e-mail]>, Ogaki, Kenichi <[e-mail]>
Cc: Lou Berger <[e-mail]>, TEAS WG Chairs <[e-mail]>, [e-mail] <[e-mail]>, TEAS WG <[e-mail]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi:

I would appreciate it if the authors can clarify the following questions:

1.   Essentially the identifier in data packet is used to identify the NRP which the packet is mapped to, and the set of resource for processing and forwarding the packet. Calling it a flow aggregate selector would confuse the boundary between service flows and the underlay network construct (which is called NRP). In my understanding, the network devices only maintain the NRP specific resource states, they (except the ingress nodes) do not need to know whether and how service flows are mapped to the NRP.
[TS]: service flows (from IETF network slices) are aggregated into Slice Flow-Aggregate (SFA) so they are given similar treatment in the network. The flow aggregate traffic carries a Flow-Aggregate Selector (FAS) to allow nodes to distinguish packets belonging to the SFA. The SFA traffic is placed on paths established over the network resources defined by the NRP.


2.   I’m a little confused about the case which multiple VPN labels are used to identify a Slice Flow Aggregate. The VPN service label are usually called service label, it is not clear how a service label can be used to identify a flow aggregate. And since this data plane ID need to be processed by intermediate nodes, can the VPN labels be parsed and processed by the intermediate nodes? BTW, the text in section 5.1.1 describes several options of encapsulating the identifier in MPLS packet header, which does not belong to a TEAS document, better to move them to an MPLS draft.

[TS]: the document describes that a FAS can take several forms and depending on the specifc dataplane (e.g., MPLS, IPv6, etc.). The use of the service labels was an example for illustration only. The document already references MPLS documents (e.g., I-D.kompella-mpls-mspl4fa and I-D.decraene-mpls-slid-encoded-entropy-label-id) where proposals allow carrying the FAS in the MPLS label stack.

Regards,
Tarek (for co-authors)

Thanks

Zhibo
From: Teas [mailto:[e-mail]] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, February 24, 2022 11:04 PM
To: Ogaki, Kenichi <[e-mail]>
Cc: Lou Berger <[e-mail]>; TEAS WG Chairs <[e-mail]>; [e-mail]; TEAS WG <[e-mail]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Kenichi, Hi!

Thanks for the review! This draft discusses the use of Network Resource Partition (NRP) to support a Slice-Flow Aggregate. The NRP identifier is unique within an NRP domain and is meant for use in the control/management plane to identify the resources associated with the NRP (this should be the identifier used in any relevant control-plane protocol extensions).

The NRP-ID is not the same as Flow-Aggregate Selector (FAS). The FAS is quite simply the marking in the data plane packet that identifies a Slice-Flow Aggregate. The same Slice-Flow Aggregate may be identified by multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 where a range of VPN service labels – each acting as a FAS – select the same Slice-Flow Aggregate). The solution architecture leaves room for an implementation to overload the NRP-ID and use it as a FAS – but that is strictly an implementation choice.

And yes, we do expect all other related work to eventually align and adhere to what is specified in this document.

Regards,
-Pavan (as co-author)

On Thu, Feb 24, 2022 at 3:14 AM Ogaki, Kenichi <[e-mail]<mailto:[e-mail]>> wrote:
Hi Authors,

I'd just like to clarify.
Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig. 1 in this draft, I understand that this draft also describes one of solutions realizing Network Resource Partition(NRP).
If my understanding is correct, NRP-ID is essentially same as FASL and "Slice Aggregate ID" described at Fig.5 in draft-bestbar-lsr-slice-aware-te-00.
>From an operational perspective, it's burden to manage many slice related components and the mappings of these components, e.g. connectivity matrix <-> IETF network slice <-> Slice-flow Aggregate <-> FAS <-> NRP.
Do authors have any thought to at least unify these identifiers in a series of bestbar drafts. Or, is there any reason not able to unify these?

Thanks,
Kenichi
-----Original Message-----
From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Lou Berger
Sent: Friday, February 18, 2022 10:28 PM
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas