Hi Greg, I have described my thoughts on eth case, mainly from the registry point of view. And I think Robert has explained the value of SRH. On YANG, it can only configure a node with existing capabilities. It cannot make a node to support DoH or SRH or even bypass, if this node does not have the implementation.
Cheers, Tianran ________________________________ Sent from WeLink 发件人： Greg Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 收件人： Tianran Zhou<zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> 抄送： xiao.min2<xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;ipv6<i...@ietf.org<mailto:i...@ietf.org>>;giuseppe.fioccola=40huawei.com<giuseppe.fioccola=40huawei....@dmarc.ietf.org<mailto:giuseppe.fioccola=40huawei....@dmarc.ietf.org>> 主题： Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method 时间： 2023-02-18 05:34:32 Hi Tianran, I cannot consider SRv6 to be a separate, different data plane from IPv6. In fact, since IP is not putting packets on a wire but uses lower-layer encapsulation, SRv6 and IPv6 share the same data plane encoding, for example, Ethernet. Furthermore, as I've described in my note to Robert, an implementation based on RFC 9343 can be already used in an SRv6 domain with any degree of flexibility that is required by an operator. That flexibility, as I imagine, will be provided based on the Alternate Marking YANG data model applied to the IPv6 environment. True, the solution proposed in the draft may provide some performance improvement, but I don't see it as a significant enough benefit in processing to justify a solution to the scenario that is already addressed. Regards, Greg On Thu, Feb 16, 2023 at 8:51 PM Tianran Zhou <zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> wrote: Hi Greg, I did not follow the discussion on the ethertype case. But I think it’s different from this case alt-mk on srv6. If I were there on ethertype discussion, I would consider ethertype will explode with more and more similar applications. And ethertype is not in iana registry, but in ieee. This draft applies for srh tlv, which does not have the same concern, not the same space as ipv6 option. I do not understand the “burden” you mentioned. Vendors can choose the implementation they need. I do not believe any vendor implements all the RFCs. On the other hand, the latest revision as Giuseppe posted includes deployment considerations on IPv6 or SRv6. I see Aijun also gave a good proposal. Best, Tianran From: ipv6 [mailto:ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>] On Behalf Of Greg Mirsky Sent: Friday, February 17, 2023 12:56 AM To: xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> Cc: spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; giuseppe.fioccola=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org> Subject: Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Dear All, I believe that Xiao Min expressed also my concerns about proposals to standardize multiple encodings for the IPv6 data plane. It seems that it is helpful to recall that SRv6 shares with IPv6 the same EtherType value. Thus, differentiating between IPv6-generic and SRv6-only encodings for the same operation presents, in my opinion, an additional burden for fast-path processing. I recall that there was an idea to assign SRv6 a new, different from IPv6 Ether Type, value. As I understand it, that idea did not receive sufficient support. Thus, as IPv6 and SRv6 share the same data plane, I believe that the encoding for on-path telemetry collection must be common for IPv6 and SRv6. Regards, Greg On Tue, Feb 14, 2023 at 6:16 PM <xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>> wrote: Hi Giuseppe, Haoyu, Thank you for the response and explanation. AFAIK, there is no precedent to standardize two or more data planes for one purpose, of course, if the SPRING WG has (rough) consensus to create such a precedent, that's ok for me. For your reference, there was a good example in NVO3 WG on how to handle multiple data plane proposals. The decision was to standardize Geneve (now RFC 8926) while allowing other proposals to proceed as Informational documents. Cheers, Xiao Min Original From: HaoyuSong <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> To: Giuseppe Fioccola <giuseppe.fioccola=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>>;肖敏10093570;j...@joelhalpern.com<mailto:j...@joelhalpern.com> <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Cc: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>;i...@ietf.org<mailto:i...@ietf.org> <i...@ietf.org<mailto:i...@ietf.org>>; Date: 2023年02月11日 01:25 Subject: Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring IMO，the method in this draft clearly defines the AM effective scope by data plane encapsulation itself. It avoids the need of using two EHs to achieve the goal. Using two EHs not only bloats the header size but also requires cumbersome configurations to the non-SR routers. In either case (SRH or DOH encapsulation), the AM processing is the same which accounts for the major implementation cost. However, the introduction of SRH encapsulation can reduce the overall system cost in the SRv6 scenario. Best, Haoyu From: ipv6 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of Giuseppe Fioccola Sent: Friday, February 10, 2023 1:08 AM To: xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>; j...@joelhalpern.com<mailto:j...@joelhalpern.com> Cc: spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org> Subject: Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Hi Xiao, Thank you for the feedback. As also discussed with Greg, this is a general issue if you want to add on-path information for SRv6 and avoid some limitations with the option header (RFC 9098 and draft-ietf-6man-eh-limits). I think that, for SRv6, a more robust way can be to integrate the data fields directly into the SRH, since there is the possibility to define dedicated TLVs. Regards, Giuseppe From: ipv6 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> Sent: Friday, February 10, 2023 3:53 AM To: j...@joelhalpern.com<mailto:j...@joelhalpern.com> Cc: spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org> Subject: Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Hi Joel, et al., As a verndor having implemented the encapsulation *put the Alternate Marking encodings in the Destination Option preceding an SRH* [RFC 9343], I regard the encapsulation *put the Alternate Marking encodings in the SRH TLV* [draft-fz-spring-srv6-alt-mark] as a burden. Note that it's a data plane encapsulation, one solution is preferred always, unless the newly introduced one has significant advantage (in some aspects, to some people), it's not the case to me, the potential benefit to use one IPv6 extension header (SRH) instead of two (DOH+SRH) doesn't mitigate my concern. :( Best Regards, Xiao Min Original From: JoelHalpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; Cc: 6man <i...@ietf.org<mailto:i...@ietf.org>>; Date: 2023年02月02日 08:45 Subject: [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method This call is for the draft at: https://datatracker.ietf.org/doc/draft-fz-spring-srv6-alt-mark<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fz-spring-srv6-alt-mark&data=05%7C01%7Chaoyu.song%40futurewei.com%7Ca656a2c5fc5845caeb4d08db0b466c20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116169340368509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KiDUrI4cNbVJc4a23yAgAsNISUwY39bOghRfif6zcfE%3D&reserved=0> This email starts the WG adoption call for the subject draft (as requested by the authors, with apologies from the WG chairs for how long it has taken to kick this out.) This call will run through the end of the day on Feb 16. Pleaes read the whole email as there are a few points, and it is not that long. Please comment on whether you think this topic is something you think the spring WG should work, whether you think this draft is a good starting point for such work, any issues or concerns you have, and whether you would be willing to help be contributing and / or reviewing the work if the WG does choose to work on it. 6man is copied for their information, as this is different from but related to an extension header proposal in front of 6man. Authors and named contributors, please confirm to the list that all known, relevant, IPR has been disclosed. If it has note, please remedy this gap. The spring chairs have noted one aspect of this draft that caught our eye, and we would appreciate WG members who comment on the adoption to consider, and if possible opine, on this. As we read this draft, as distinct from the related 6man extension header work, this causes the recorded altmarks to only be updated at routers identified in the SRH segment list. (We presume this would include all identified points in a compressed container.) We could not tell from the document what the value was for this as distinct from getting the measurements at all routers. Do WG members understand and agree that it does have value? As a lesser point, we consider that one quote in the draft is misleading and will likely need to be reworded in the near future. The draft say "SRH TLV can also be used to encode the AltMark Data Fields for SRv6 and to monitor every node along the SR path." It is unclear if these was intended to mean all routers (most of which would not see this TLV) or if it was intended to refer to only those routers identified in the SRH, in which case we presume it will be reworded. Thank you, Joel _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=05%7C01%7Chaoyu.song%40futurewei.com%7Ca656a2c5fc5845caeb4d08db0b466c20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116169340368509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Bq2cJMycTZKjss%2B%2F6S8uLcDWFDfQPGJYq8ZMLZoEduc%3D&reserved=0> -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
