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

[[e-mail]]

Thank you, Behcet & Med,




Will use TBD and let IANA assign the correct value later on.








Best Regards,


 






魏月华 Yuehua Wei






M: [phone] E: [e-mail]









原始邮件



发件人：BehcetSarikaya
收件人：Mohamed Boucadair;
抄送人：魏月华00019655;[e-mail];
日 期 ：2021年01月08日 01:16
主 题 ：Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt


_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc






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]>のメール:
 >>
 >> 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] <mailto:[e-mail]> 
 >> <[e-mail] <mailto:[e-mail]>>
 >> *收件人：*[e-mail] <mailto:[e-mail]> 
 >> <[e-mail] <mailto:[e-mail]>>;
 >> *抄送人：*[e-mail] <mailto:[e-mail]> <[e-mail] 
 >> <mailto:[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]>
 >> 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