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>
To: Giuseppe Fioccola
<giuseppe.fioccola=40huawei....@dmarc.ietf.org>;肖敏10093570;j...@joelhalpern.com
<j...@joelhalpern.com>;
Cc: spring@ietf.org <spring@ietf.org>;i...@ietf.org <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
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> On Behalf Of Giuseppe Fioccola
Sent: Friday, February 10, 2023 1:08 AM
To: xiao.m...@zte.com.cn; j...@joelhalpern.com
Cc: spring@ietf.org; 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> On Behalf Of xiao.m...@zte.com.cn
Sent: Friday, February 10, 2023 3:53 AM
To: j...@joelhalpern.com
Cc: spring@ietf.org; 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>
To: SPRING WG List <spring@ietf.org>;
Cc: 6man <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
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
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
