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

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.