Re: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt

[Huaimo Chen <[e-mail]>]

Hi Ketan,

    Thank you very much for your review and 6 specific comments.
    My responses are inline below with [HC].

  1.  FlowSpec v1 is supposed to be focussed on the DDOS use-case.
I don't find any text in the draft that clarifies how/why this is
related to DDOS use-case. To me, this seems like something for
FlowSpec v2. Per (what I understood to be) WG consensus, this work
is then perhaps deferred to v2.
[HC]: This draft is for FlowSpec v2.

  2.  The draft proposes a new type "Whole SID". My understanding
from the text is that this rule applies to the IPv6 DA and not the
segments within the SRH. If so, then:
     *   What distinguishes a SID from any other IPv6 address in the
DA field?
[HC]: It is a kind of post processing SRv6 PGM that we are matching
on the DA after the SID has been copied from the SRH header to the
DA and SL decremented SL=SL-1.

     *   Why isn't the existing IPv6 DA type not sufficient?
[HC]: It is sufficient but it is the post SRv6 processing after the
SID is copied from SRH to DA when the next hop steering occurs. The
new type can provide some SID specific operations.

  3.  The draft proposes a new type "Some bits of SID (SBoS)".
Again, I believe this applies to the IPv6 DA again - so the same two Qs
above apply to this type to. What prevents a router (mistakenly)
applying this rule to packets with non-SRv6 SID in their DA.
[HC]: Refer to the answers above to the same questions.
A router MUST determine the IPv6 DA is a SID first and then
applies this rule only when the IPv6 DA is a SID.
This can be achieved by applying the rule as a post processing SRv6 PGM.

  4.  When the SBoS type is used, the SRv6 SID structure MUST be
indicated as part of the rule. Then the parts of the SID of interest
that need to be matched are also given in the space for the SID.
Is my understanding correct? If so, the text was not very clear to me.
[HC]: You are right. We will add some descriptions to make it clear.

  5.  The question of why this SBoS type is required again crops us
since the base FlowSpec rule for DA does allow pattern matching on
the IPv6 DA as well? Perhaps I am mistaken, and if so the document
does not provide any text or justification for why these new types
are required.
[HC]: A SRv6 SID has a specific structure with different fields.
Some fields in a SID may have some specific values. For example,
VPN service labels are embedded into some fields such as Func/Arg
of the SRv6 SIDs in some cases. This SBoS type can provide some
specific operations on some fields in a SID. For example, the service
labels in Func/Arg of SRv6 SIDs are within a given range. We may
check the ranges of the values in the fields using SBoS type.
We will add some text for justification.

  6.  Finally, there is no text related to the specific applicability
scenarios for these extensions. Exactly why it is difficult to
determine whether this falls under v1 or v2 scope.
[HC]: We will add some examples using these extensions.

Best Regards,
Huaimo
on behalf of co-authors

________________________________
From: Ketan Talaulikar (ketant) <[e-mail]>
Sent: Friday, July 30, 2021 8:18 AM
To: Susan Hares <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt

Hello,

I have reviewed https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-li-idr-flowspec-srv6-05&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C0b12565f359d468e7d8308d9535439c6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637632443513317218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=dFhw6e%2F%2BR0%2BkDcGsjOlf2A4MmbuB080PIoBqTi99%2Bt0%3D&amp;reserved=0 and have the following questions for the authors before we consider adoption.


  1.  FlowSpec v1 is supposed to be focussed on the DDOS use-case. I don't find any text in the draft that clarifies how/why this is related to DDOS use-case. To me, this seems like something for FlowSpec v2. Per (what I understood to be) WG consensus, this work is then perhaps deferred to v2.
  2.  The draft proposes a new type "Whole SID". My understanding from the text is that this rule applies to the IPv6 DA and not the segments within the SRH. If so, then:
     *   What distinguishes a SID from any other IPv6 address in the DA field?
     *   Why isn't the existing IPv6 DA type not sufficient?
  3.  The draft proposes a new type "Some bits of SID (SBoS)". Again, I believe this applies to the IPv6 DA again - so the same two Qs above apply to this type to. What prevents a router (mistakenly) applying this rule to packets with non-SRv6 SID in their DA.
  4.  When the SBoS type is used, the SRv6 SID structure MUST be indicated as part of the rule. Then the parts of the SID of interest that need to be matched are also given in the space for the SID. Is my understanding correct? If so, the text was not very clear to me.
  5.  The question of why this SBoS type is required again crops us since the base FlowSpec rule for DA does allow pattern matching on the IPv6 DA as well? Perhaps I am mistaken, and if so the document does not provide any text or justification for why these new types are required.
  6.  Finally, there is no text related to the specific applicability scenarios for these extensions. Exactly why it is difficult to determine whether this falls under v1 or v2 scope.

Thanks,
Ketan

From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: 23 July 2021 22:28
To: [e-mail]; [e-mail]
Subject: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt

This begins a 2 week WG adoption call for draft-li-idr-flowspec-srv6-05.txt