Re: [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02

We do need an identifier for the NRP so that it can be used in the control
or management plane to reference the resources associated with the NRP.
This is the identifier that should get used in any relevant control-plane
protocol extensions introduced for referencing an NRP.

I believe the debate here is only with regards to the use of the NRP-ID in
the dataplane. As discussed in draft-ietf-teas-ns-ip-mpls, for certain
service profiles (acknowledge that not all service profiles need this)
where there is a need to provide specific forwarding treatment for packets
belonging to a Slice-Flow Aggregate, the packets need to carry some
“marking” that can be mapped to an NRP. draft-ietf-teas-ns-ip-mpls refers
to such marking as Flow-Aggregate Selector (FAS) and describes several
options for encoding the FAS in the packet. The discussion in the draft
also leaves room for multiple different selectors to be mapped to the same
NRP (many to one mapping).

With respect to draft-dong-teas-nrp-scalability, it talks about encoding
the NRP-ID as a FAS (assumes 1-1 mapping) in the packet and discusses the
scalability aspects associated with doing so. I see this option as one
specific implementation choice for defining the FAS (and note the presence
of other options).

Regards,

-Pavan (as a WG participant)

On Wed, Jun 22, 2022 at 8:03 AM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Med,
>
> Thanks again for your review, yes the changes will be reflected in next
> update.
>
> And please see some replies inline:
>
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > [mailto:mohamed.boucadair@orange.com]
> > Sent: Tuesday, June 21, 2022 7:17 PM
> > To: Dongjie (Jimmy) <jie.dong@huawei.com>; Lou Berger <lberger@labn.net
> >;
> > TEAS WG <teas@ietf.org>
> > Cc: TEAS WG Chairs <teas-chairs@ietf.org>
> > Subject: RE: [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02
> >
> > Hi Jie,
> >
> > Thanks for the replies in the doc file. Much appreciated. I trust that
> changes
> > will be made to the document to reflect the comments/replies.
> >
> > I'm still not convinced that having a discussion about VPN+ is
> justified, but
> > that's a minor point at this stage.
> >
> > For this pending point:
> >
> > > > > Good question. The WG may need to discuss what types of slice
> > > > > related identifiers are needed.
> > > >
> > > > [Med] However that discussion need to take place before digging
> > > into
> > > > optimization matters (this draft, for example).
> > >
> > > My understanding is the WG have had the discussion about what
> > > information is needed in the underlay network. According to that
> > > discussion, a network needs to be aware of the underlay constructs
> > > (i.e. NRPs) to apply different forwarding treatment to packets which
> > > are mapped to different NRPs.
> >
> > The point is that there are various ways to achieve that mapping.
>
> Agree there can be different ways to achieve the mapping, and the result
> would be the same: network slice services are mapped to the same or
> different NRPs.
>
> The forwarding treatment of packet is determined based on which NRP the
> packet is mapped to.
>
> >
> > Assuming that an extra identifier is needed, the questions I have are
> still
> > unanswered:
> > * Should that identifier be a slice id? a slice aggregate id? etc.
> > * If such identifiers are justified, why an additional NRP id is needed?
> > * The other way around is also valid: if we have an NRP id, do we need a
> > slice-id to be signaled as well?
>
> As John mentioned, nodes in the network does not need to know the slice ID
> (the ID of the slice service) for packet forwarding.
>
> Slice Aggregate or Slice Flow Aggregate is one way of mapping slice
> services to NRPs, in that case the term slice aggregate ID is equivalent to
> NRP ID.
>
> Best regards,
> Jie
>
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Teas <teas-bounces@ietf.org> De la part de Dongjie (Jimmy) Envoyé
> > > : mardi 21 juin 2022 05:45 À : BOUCADAIR Mohamed INNOV/NET
> > > <mohamed.boucadair@orange.com>; Lou Berger <lberger@labn.net>;
> > TEAS WG
> > > <teas@ietf.org> Cc : TEAS WG Chairs <teas-chairs@ietf.org> Objet : Re:
> > > [Teas] WG adoption poll: draft-dong-teas-nrp-
> > > scalability-02
> > >
> > > Hi Med,
> > >
> > > Please find my replies to your review comments in the following
> > > link:
> > >
> > > https://github.com/jie-dong/ietf-drafts/blob/main/draft-dong-teas-
> > > nrp-scalability-02-rev%20Med-reply%20Jie_220620.doc
> > >
> > > And please see some further replies inline:
> > >
> > > > > The concepts network slice, network slice service and NRP are
> > > > > described in draft-ietf-teas-ietf-network-slices, this
> > > document
> > > > > follows these concepts and mainly focus on the scalability of
> > > NRP.
> > > >
> > > > [Med] I see some uses in the draft where this is not well
> > > aligned. I
> > > > indicated some of them in the edited copy, but please double
> > > check the
> > > > text and update as appropriate.
> > >
> > > Thanks for pointing it out, we will better align the use of the terms
> > > in next update.
> > >
> > > > > Good question. The WG may need to discuss what types of slice
> > > > > related identifiers are needed.
> > > >
> > > > [Med] However that discussion need to take place before digging
> > > into
> > > > optimization matters (this draft, for example).
> > >
> > > My understanding is the WG have had the discussion about what
> > > information is needed in the underlay network. According to that
> > > discussion, a network needs to be aware of the underlay constructs
> > > (i.e. NRPs) to apply different forwarding treatment to packets which
> > > are mapped to different NRPs.
> > >
> > > > > As for this document, as it focuses on the NRP which is
> > > allocated
> > > > > with a set of network resources, the NRP specific identifiers
> > > are
> > > > > used to determine the different set of resources allocated in
> > > the network.
> > >
> > > > [Med] Looking forward seeing that clarified/discussed.
> > >
> > > Please see the replies in the provided link, thanks.
> > >
> > > Best regards,
> > > Jie
> > >
> > > >
> > > > > Best regards,
> > > > > Jie
> > > > >
> > > > > >
> > > > > > 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.
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > 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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>