Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt

[Behcet Sarikaya <[e-mail]>]

On Thu, Jan 7, 2021 at 9:44 AM <[e-mail]> wrote:

> Hi Wei,
>
>
>
> Thank you for sharing this updated version.
>
>
>
> One quick comment: Please remove this line from Section 7 as that value is
> already assigned to the service identifier TLV.
>

Wei, just use TBD and let IANA assign the correct value later on.

Behcet

>
>
> | 0x00  |             Reserved             | This document |
>
>
>
> I still do think that more text is needed to understand the usage of the
> various attributes.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc [mailto:[e-mail]] *De la part de*
> [e-mail]
> *Envoyé :* mardi 5 janvier 2021 03:29
> *À :* [e-mail]
> *Objet :* [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt
>
>
>
> Dear chairs and SFCers，
>
> I uploaded ver04 of “
> Network Service Header Metadata Type 2 Variable-Length Context Headers”
> draft.
>
> I updated the draft according to the comments received from the SFC
> mailing list.
>
>
>
> Your comments are always welcome and helpful.
>
>
>
> And I would like to ask the WG for the consideration of the WGLC.
>
> Thank you!
>
> ------
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
>
>
>         Title           : Network Service Header Metadata Type 2 Variable-Length Context Headers
>         Authors         : Yuehua (Corona) Wei
>                           Uri Elzur
>                           Sumandra Majee
>                           Carlos Pignataro
>     Filename        : draft-ietf-sfc-nsh-tlv-04.txt
>     Pages           : 13
>     Date            : 2021-01-04
>
> Abstract:
>    This draft describes Network Service Header (NSH) Metadata (MD) Type
>    2 variable-length context headers that can be used within a service
>    function path.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-04
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-04
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>
>
> Yuehua Wei
>
> *Best Regards,*
>
> M: [phone] E: [e-mail]
>
>
>
> 原始邮件
>
> *发件人：*JoelM.Halpern
>
> *收件人：*Carlos Pignataro (cpignata);
>
> *抄送人：*[e-mail];
>
> *日 **期 * *：*2020年05月27日 23:40
>
> *主 **题 **：Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt*
>
> Thank you for your extensive work on this Carlos.
>
> Working group...   Does anyone else have comments?  This is another
> milestone we need to get done.
>
> Yours,
> Joel
>
> On 5/27/2020 10:33 AM, Carlos Pignataro (cpignata) wrote:
> > Dear Wei,
> >
> > Thanks for addressing the vast majority of my comments from two full
> > reviews, and incorporating all my textual suggestions.
> >
> > Some still remain:
> >
> > 1.  s/byte/octet/g —> there are still 4 instances of “byte”.
> >
> > 2. Content Type
> >
> > 4.3.  Content Type
> >
>
> > I’d recommend removing this one. It does not seem to be adequately defined.
> >
> > 3. Note ID
> >
> >                       Figure 6: Ingress Network Node ID
> >
> > Why is the length fixed to 8? I understand a 32-bit number can be a most
> > common Node ID, but what if a 128-bit number wants to be used?
> >
> > I’d allow either of two lengths.
> >
> > 4. Flow ID
> >
> > 4.6.  Flow ID
> >
> >     Flow ID provides a representation of the flow.  Akin, but not
> >     identical to the usage described in [RFC6437].
> >
> >
> > This still needs to be more appropriately defined. I would replace:
> >
> >     Flow ID provides a representation of the flow.  Akin, but not
> >     identical to the usage described in [RFC6437].
> >
> > With at least
> >
> >     The Flow ID provides a field in the NSH MD Type 2 to label
> >     packets belonging to the same flow.  Absence of this field, or
> >     a value of zero denotes that packets have not been labeled.
> >
> >
> >
> > 5. IANA
> >
> >     This document defines the following new values (Table 1)in the
> >     Network Service Header (NSH) metadata context Type registry:
> >
> >
> > There’s a space missing in the first line.
> >
> > More importantly though, I would add two Experimentation values in Table
> > 1. I would also reserve the value of 0x00.
> >
> >
> > 6. IANA Citation.
> >
> > I think the URI for IANA should be without the file part:
> >
> https://www.iana.org/assignments/nsh/#optional-variable-length-metadata-types
> >
> >
> > Lastly, here is some of the text proposed for some section descriptions:
> >
> > Forwarding Context
> >
> >     The forwarding context used for segregation and forwarding scope can
> >     Take several forms depending on the network environment. For example,
> > VXLAN/VXLAN-GPE VNID, VRF identification, and VLAN. This context
> > header carries this network-based forwarding context.
> >
> > Tenant Identifier
> >
> >     Tenant identification is often used for segregation within a multi-
> >     tenant environment.  Orchestration system-generated tenant IDs are an
> >     example of such data. This context header carries both the format and
> >     value of the Tenant identifier.
> >
> > Content Type
> >
> > // Remove
> > // I believe this needs further thinking on the namespace fo Content
> > Types, could even be draft-penno-sfc-appid-05
> >
> > Ingress Network Node Information
> >
> >     This context header identifies the ingress network node.
> >
> > Ingress Network Interface Information
> >
> >     This context header identifies the ingress network interface.
> >
> > Flow ID
> >
> >     The Flow ID provides a field in the NSH MD Type 2 to label
> >     packets belonging to the same flow.  Absence of this field, or
> >     a value of zero denotes that packets have not been labeled.
> >
> >
> > Thanks!
> >
> > Carlos.
> >
> >
> >> 2020/05/20 午後11:05、[e-mail]
> >> <mailto:[e-mail] <[e-mail]>>のメール:
> >>
> >> Hi folks,
> >>
> >> I just uploaded a new version of NSH metadata 2 variable-length
> >> context headers.
> >>
> >> The updates resolved the comments received from the mailing list.
> >>
> >> One important technical modification is splitting of the Ingress
> >> Network context header to two context headers (in 4.4 and 4.5) which
> >> is proposed by Carlos, Med and Greg.
> >>
> >> Please keep reviewing and give your comments.
> >>
> >> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>
> >>
> >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03..txt
> >> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>
> >>
> >>
> >> In addition,  I would as the  WG to consider changing the length
> >> of Tenant Identifier context header ( in 4.2) to "var", so that TT and
> >> IANA sub-registry are not needed.
> >>
> >>
> >> Thank you for your kind support.
> >>
> >>
> >> *Best Regards,*
> >> *魏月华 Corona Wei*
> >>
> >> *ZTE Corporation*
> >>
> >> M: [phone] E: [e-mail] <
> mailto:[e-mail] <[e-mail]>>
> >>
> >>
> >> 原始邮件
> >> *发件人：*[e-mail] <mailto:[e-mail]
> <[e-mail]>>
> >> <[e-mail] <mailto:[e-mail]>>
> >> *收件人：*[e-mail] <mailto:[e-mail]
> <[e-mail]>>
> >> <[e-mail] <mailto:[e-mail]>>;
> >> *抄送人：*[e-mail] <mailto:[e-mail] <[e-mail]>> <[e-mail]
> <[e-mail]%C2%A0%0b>>> <mailto:[e-mail] <[e-mail]>>>;
> >> *日 期 ：*2020年05月21日 08:40
> >> *主 题 ：**[sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt*
> >>
>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> >> This draft is a work item of the Service Function Chaining WG of the IETF.
> >>
>
> >>         Title           : Network Service Header Metadata Type 2 Variable-Length Context Headers
> >>         Authors         : Yuehua (Corona) Wei
> >>                           Uri Elzur
> >>                           Sumandra Majee
> >>     Filename        : draft-ietf-sfc-nsh-tlv-03.txt
> >>     Pages           : 12
> >>     Date            : 2020-05-20
> >>
> >> Abstract:
> >>    This draft describes Network Service Header (NSH) Metadata (MD) Type
> >>    2 variable-length context headers that can be used within a service
> >>    function path.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-03
> >> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-03
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03
> >>
> >>
>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sfc
> >>
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> [e-mail] <mailto:[e-mail] <[e-mail]>>
> >> https://www.ietf.org/mailman/listinfo/sfc
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
> >
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>