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

[[e-mail]]

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.  

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? 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[e-mail]> De la part de Dongjie (Jimmy)
> Envoyé : mardi 21 juin 2022 05:45
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> Lou Berger <[e-mail]>; TEAS WG <[e-mail]>
> Cc : TEAS WG Chairs <[e-mail]>
> 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
> [e-mail]
> 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.