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

[Tarek Saad <[e-mail]>]

From: Loa Andersson <[e-mail]>
Date: Sunday, February 27, 2022 at 11:53 PM
To: Tarek Saad <[e-mail]>, Huzhibo <huzhibo=[e-mail]>, 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
Tarek,

Inline please.

On 2022-02-28 12:38, Tarek Saad wrote:
> 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.

Are you saying that SFA's have the same FEC? If so are we inventing the
wheel again?

[TS]: No. It is possible traffic from multiple SFAs can be forwarded over the same LSP. The presence of the FAS in packet will determine the specific forwarding treatment that would be imposed on packets belonging to the respective SFA.

Regards,
Tarek


/Loa
>
> 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/
>     <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
>     <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
>     <https://www.ietf.org/mailman/listinfo/teas>
>     _______________________________________________
>     Teas mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas

--
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]