Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hi Huaimo, Thanks a lot for your review and comments. Please find my responses in line [Yali]. Best regards, Yali From: Huaimo Chen [mailto:huaimo.c...@futurewei.com] Sent: Tuesday, November 17, 2020 12:59 PM To: wangyali ; lsr@ietf.org Subject: Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hi Authors, The draft describes extensions to IGP for a node to distribute capabilities of its links. The capability information about all the links in a network may be used by another entity such as a controller. I have following comments: 1). In section 3, the capabilities of a link or a node is represented by "Processing Action" (refer to Fig. 1 in the draft). Why do you include "Max EH Len" in the "Processing Action"? It is not a capability. [Yali] Since the length of IPv6 Extensions Header exceeds the maximum limit the node is capable to process, the packets carried extensions header should be discarded. Hence, "Max EH Len" defined in this draft is used to indicate the maximum length of extension header supported by the Node or Link. So I think it is also a capability. What's your thoughts? 2). The text describing the format of "Processing Action" below seems not consistent with the format in Fig. 1. "... processing action formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag." The above text occurs twice in the draft. [Yali] I'll fix this in the next version. It should be "...processing action formed of a tuple of a 8-bit Processing Action Flag, a 16-bit Services Flag, and a one-octet Maximum Extensions Header Length." 3). It seems that using word "signal" or "signaling" in the draft is not good. It is better to use another word and rephrase the related text. [Yali] I will replace word "signal" by "advertise" and also revise the related text. Is it correct? Best Regards, Huaimo From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of wangyali mailto:wangyal...@huawei.com>> Sent: Thursday, October 29, 2020 9:19 AM To: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>> Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hello WG, Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance. Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. Please let us know your opinion. Questions and comments are very welcome. Best regards, Yali -Original Message- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] Sent: Thursday, October 29, 2020 8:42 PM To: Tianran Zhou mailto:zhoutian...@huawei.com>>; Huzhibo mailto:huzh...@huawei.com>>; wangyali mailto:wangyal...@huawei.com>> Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository. Name: draft-wang-lsr-hbh-process Revision: 00 Title: IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action Document date: 2020-10-29 Group: Individual Submission Pages: 10 URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-hbh-process-00.txtdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=tvJH5rnR%2BAj%2FxTTaxxbKJ6z%2F1OKAog3QdCCJnJkKB2I%3Dreserved=0 Status: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-hbh-process%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8f
Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hi Authors, The draft describes extensions to IGP for a node to distribute capabilities of its links. The capability information about all the links in a network may be used by another entity such as a controller. I have following comments: 1). In section 3, the capabilities of a link or a node is represented by "Processing Action" (refer to Fig. 1 in the draft). Why do you include "Max EH Len" in the "Processing Action"? It is not a capability. 2). The text describing the format of "Processing Action" below seems not consistent with the format in Fig. 1. "... processing action formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag." The above text occurs twice in the draft. 3). It seems that using word "signal" or "signaling" in the draft is not good. It is better to use another word and rephrase the related text. Best Regards, Huaimo From: Lsr on behalf of wangyali Sent: Thursday, October 29, 2020 9:19 AM To: lsr@ietf.org Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hello WG, Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance. Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. Please let us know your opinion. Questions and comments are very welcome. Best regards, Yali -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, October 29, 2020 8:42 PM To: Tianran Zhou ; Huzhibo ; wangyali Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository. Name: draft-wang-lsr-hbh-process Revision: 00 Title: IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action Document date: 2020-10-29 Group: Individual Submission Pages: 10 URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-hbh-process-00.txtdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=tvJH5rnR%2BAj%2FxTTaxxbKJ6z%2F1OKAog3QdCCJnJkKB2I%3Dreserved=0 Status: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-hbh-process%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=Wt7W0PL8HGI1EaPK8sV92RWIRGXATD0RGx1AhGIH6xk%3Dreserved=0 Htmlized: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-hbh-processdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=Zmi3lDpE2aNulJxCiyU%2B9XQzv63EPeMo%2BAWVkatiDRE%3Dreserved=0 Htmlized: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-hbh-process-00data=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=m9Z1uy3W4tT73SQod1DpcT%2BU4malMI25xQtNHTSwkdY%3Dreserved=0 Abstract: This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IO
Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hi Huanan, Thanks for your review and comments. Please see inline [Yali]. Please feel free let us know your thoughts. From: chenhu...@chinatelecom.cn [mailto:chenhu...@chinatelecom.cn] Sent: Monday, November 16, 2020 10:00 AM To: wangyali ; lsr@ietf.org Subject: Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hello WG and Authors, I have read the draft. It is a good idea to use IGP extension to notification the HBH ablility. Commments as follow: 1. How to enable the IGP extensions for HBH？ [Yali] The Hop-by-Hop Options header processing action TLVs defined in this draft, for example, can be enabled in IGP through configuration. 2. Does the IGP use the HBH option as criterion to genernate a new topology? [Yali] The topology are not changed and affected. Such advertisements can allow entities (e.g. centralized controllers) to exclude nodes that are not HbH-capable when paths are computed for specific services. For example, if you need a private line that must be measured by IOAM or IFIT, you can exclude nodes that are not HbH-capable during path computation for making sure performance data can be collected and exported at every HbH-capable nodes in the private line. BR. Huanan Chen From: wangyali<mailto:wangyal...@huawei.com> Date: 2020-10-29 21:19 To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hello WG, Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance. Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. Please let us know your opinion. Questions and comments are very welcome. Best regards, Yali -Original Message- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] Sent: Thursday, October 29, 2020 8:42 PM To: Tianran Zhou mailto:zhoutian...@huawei.com>>; Huzhibo mailto:huzh...@huawei.com>>; wangyali mailto:wangyal...@huawei.com>> Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository. Name: draft-wang-lsr-hbh-process Revision: 00 Title: IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action Document date: 2020-10-29 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/ Htmlized: https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process Htmlized: https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00 Abstract: This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network. 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. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hello WG and Authors, I have read the draft. It is a good idea to use IGP extension to notification the HBH ablility. Commments as follow: 1. How to enable the IGP extensions for HBH？ 2. Does the IGP use the HBH option as criterion to genernate a new topology? BR. Huanan Chen From: wangyali Date: 2020-10-29 21:19 To: lsr@ietf.org Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00 Hello WG, Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance. Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. Please let us know your opinion. Questions and comments are very welcome. Best regards, Yali -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, October 29, 2020 8:42 PM To: Tianran Zhou ; Huzhibo ; wangyali Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository. Name: draft-wang-lsr-hbh-process Revision: 00 Title: IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action Document date: 2020-10-29 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/ Htmlized: https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process Htmlized: https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00 Abstract: This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network. 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. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] New Version for draft-wang-lsr-hbh-process-00
Hello WG, Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance. Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. Please let us know your opinion. Questions and comments are very welcome. Best regards, Yali -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, October 29, 2020 8:42 PM To: Tianran Zhou ; Huzhibo ; wangyali Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository. Name: draft-wang-lsr-hbh-process Revision: 00 Title: IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action Document date: 2020-10-29 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/ Htmlized: https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process Htmlized: https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00 Abstract: This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network. 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. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
