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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Med, 

Thanks for the discussion. Please see further clarifications inline:

> >
> > 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?

What I actually mean is the S flag may be set to different value for different sub-flows or different type of packets in a VTN. 

For example, Some flows in a VTN may be required to only use the resource of the VTN, while for some other flows of the VTN the resource of the VTN should be used if available, but the traffic must get through even if a match is not made. Another example is that for some specific OAM packets, the S bit must be set so that the test result can correctly reflect the status of the connectivity in the VTN. The S bit may also be changed during some transition scenarios. 

With the S bit in the packet, this only needs to be done on the ingress nodes. While making it a configuration knob would require every node in the network to be configured. That would be more complex and not practical. 

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

You're right that if more flags are needed at some time in the future, then they can be allocated from the Reserved field. But we already have 8 flags available and we only have used one (currently the S flag), so it does not feel like an immediate problem or even one that is likely in the foreseeable future. And, anyway, there is no real need for flag fields to be contiguous. 

So this does not feel like a very important change. A bit like "I would not have done it like this" rather than a strong technical reason to change.

Best regards,
Jie

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