Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-05.txt

[[e-mail]]

Hi Jie, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dongjie (Jimmy) <[e-mail]>
> Envoyé : vendredi 8 septembre 2023 17:01
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]
> Cc : 6man Chairs <[e-mail]>
> Objet : RE: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-
> id-05.txt
> 
> Hi Med,
> 
> Thanks for your feedback, please see inline:
> 
> > -----Original Message-----
> > From: [e-mail]
> <[e-mail]>
> > Sent: Friday, September 8, 2023 12:09 AM
> > To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
> > Cc: 6man Chairs <[e-mail]>
> > Subject: RE: [IPv6] I-D Action:
> > draft-ietf-6man-enhanced-vpn-vtn-id-05.txt
> >
> > Hi Jie, all,
> >
> > Thanks for taking care of many of the comments.
> 
> It is good to know we've resolved many of them.
> 
> >
> > On the option format itself, I still think we lack justification
> to
> > encode in the extension the behavior to follow when no matching
> entry
> > is found. A simple approach would be to get rid of the "S" bit
> and leave this as a configuration knob.
> > I would swap the Context and flag fields to have the flags near
> the reserved bits.
> 
> The reason to make it encoded in the option is that such behavior
> could be changed per-packet.

[Med] This is adding extra complexity for a usage that is not clear to me. Do you have a concrete example where the match behavior should be per packet and per VTN? 

 Depends on some policy on the headend
> node, the behavior represented by the S bit could be set for a
> specific set of packet on the specified path/VTN , while for the
> rest of traffic on the same path/VTN, the S bit is unset. Making
> it a configuration knob would either lose such flexibility, or
> introduce complex configuration on every node along the path.
> 
> In this design the flags fields are generic and can apply to VTN
> IDs with different Context Types. That's why the flags are
> preceding the Context field.

[Med] Swapping the fields does not mean that you would loose that. The benefit of swapping is that the flag fields can be extended (if needed in the future) with more adjacent bits. 

> 
> >
> > Although the discussion in Section 5, it is somehow still vague
> what
> > is eligible to be conveyed in this option. For example, I
> understand
> > that some sort of slice id is not excluded but is that only when
> a slice involves a VTN?
> >
> > ==
> >    Note that, in the context of 5G network slicing, if a
> deployment
> >    found it useful, the four-octet VTN ID field may be derived
> from the
> >    four-octet Single Network Slice Selection Assistance
> Information
> >    (S-NSSAI) defined in 3GPP [TS23501].
> > ==
> 
> The text here just provides an option that when VTN is used for
> the transport part of 5G network slicing, there could be mapping
> relationship between the 5G Slice ID (S-NSSAI) and the VTN ID of
> this option. Then according to the S-NSSAI of a 5G network slice,
> the VTN ID could be derived, and the packet could be encapsulated
> with an outer IPv6 header with the corresponding VTN ID value in
> the VTN option.

[Med] Please update that note in the draft to indicate that the option may be inserted only ** when VTN is used **. Thanks.

...
____________________________________________________________________________________________________________
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.