[Idr] Re: AD preliminary review of draft-ietf-idr-ts-flowspec-srv6-policy-04

[John Scudder <[e-mail]>]

Hi Sue,

Thanks for your reply. I’m top-posting my comments.

Regarding your first question, about whether I consulted RFC 9252, no I didn’t. However, RFC 9252 also doesn’t define the use of the Prefix-SID attribute with SAFIs 133 or 134, which is what the present draft proposes doing. So the concern stands, and indeed you captured that in your second question, "Are you concerned solely with the SAFI 133 (FSv1) and SAFI 134 (FSv1 for VPN)?” The answer to that question is, yes, that was my stop-the-presses moment (although not my sole concern). I agree with the analysis in your point 2.

Moving on to "Should we make this draft an PS or include the changes in the BESS draft?” it seems like doing it in the present draft is the right way to go: it keeps the necessary functionality and specification together in one place. By contrast, the BESS draft is entitled "SRv6 Argument Signaling for BGP Services” and I don’t think "Traffic Steering using BGP FlowSpec” is plausibly in-scope as a “BGP Service” in the BESS context. So yeah, IMO the present draft should be a PS. For clarity, I don’t think all that is needed is a line somewhere that says “it is OK to attach this attribute to SAFIs 133 and 134”, I think that is necessary but not sufficient. What is also needed is a definition of the procedures to be followed when the attribute is so attached.

That leads me to "This document has enough implementations to make it easy to swap to PS”. I guess you mean in terms of IDR process, the implementation requirement won’t hold it up. That’s good. But this does bring me back to my earlier critique, which is, to quote myself, "I am concerned that the draft is so high-level that it wouldn’t be sufficient to enable an implementor to produce an interoperable implementation”. [1] I think the draft needs a scrub to make sure it provides enough detail about its procedures, I'm not confident that all the WG needs to do is change the “intended status” header and resubmit with the new proposed status. (And maybe that wasn’t what you meant!)

In any case, it sounds like we have the beginnings of a plan even if we are still iterating on the details/next steps. I’m going to return the doc to the WG so we can move forward.

Thanks,

—John

[1] https://mailarchive.ietf.org/arch/msg/idr/UCRiIaES78Bt9_D6P5lboQlRazM/

On Nov 17, 2024, at 8:55 PM, Susan Hares <[e-mail]> wrote:

John:

My apologies for the delay in responding to you.

Keyur and I were discussing this email. Would you examine the text in
draft-ietf-idr-ts-flowspec-srv6-policy-04 to answer two questions:


  1.  Are you using RFC9252 for your judgement on AFI/SAFIs?


Text:/
   The BGP Prefix-SID defined in [RFC8669] is utilized to enable SRv6 VPN services
   [RFC9252].  SRv6 Services TLVs within the BGP Prefix-SID Attribute
   can be used to indicate the endpoint functions./

Are you using RFC8669 or RFC9252 to judge the AFI/SAFIs?

We took this text to imply RFC9252 rules, which allow for the following
AFI/SAFIs in section

SAFI                   RFC      AFI/SAFI
-------------         -------- ----------
SAFI (1)               RFC4760  [1/1, 2/1)
SAFI (2)               RFC4760  (1/2, 2/2)
SAFI (4)               RFC8277  (1, 4)
SAFI (70)              RFC7432  (1/70, 2/70)
SAFI (71)(BGP-LS)      RFC9552  (1/71, 2/71)
SAFI (72)(BGP-LS VPN)  RFC9552  (1/72, 2/72)
SAFI (128) MPLS LU VPN RFC4364, (1/128, 2/128)
                       RFC8277,
                       RFC9252
                       RFC4659

Text from RFC9552/
   When an egress PE is enabled for BGP Services over the SRv6 data
   plane, it signals one or more SRv6 Service SIDs enclosed in an SRv6
   Service TLV(s) within the BGP Prefix-SID attribute attached to
   Multiprotocol BGP (MP-BGP) Network Layer Reachability Information
   (NLRI) defined in [RFC4760], [RFC4659], [RFC8950], [RFC7432],
   [RFC4364], and [RFC9136], where applicable, as described in Sections
   5 and 6./



  1.  Are you concerned solely with the SAFI 133 (FSv1) and SAFI 134 (FSv1 for VPN)?


SAFI 133 -  RFC8955, RFC8956, RFC9117  1/133, 2/133
SAFI 134 -  RFC8955, RFC8956, RFC9117  1/133, 2/133

You are correct that RFC9252 does not specify FSv1 SAFIs (133 and 134) as
one of the possible AFI/SAFIs the BGP prefix can be attached to.

Draft-ief-idr-ts-flowspec-srv6-policy-04 states:

/  For SRv6 scenarios, this document proposes carrying the Color
   Extended Community, the Flow-spec Redirect to IPv6 Extended Community
   and BGP Prefix-SID Attribute in the context of a Flowspec NLRI
   [RFC8955] [RFC8956] to an SRv6 Headend to steer traffic into one SRv6
   Policy, as well as to indicate specific Tailend functions./

Here the text says
MPLS-SR
NLRI: (1/133, 2/133, 1/134, 2/134)
Ext-Com: Color, redirect-ipv4

SRv6
NLRI: (1/133, 2/133, 1/34, 2/134)
Ext-Com: Color, redirect-ipv6, prefix-SID

You are correct that the RFC9252 does included the FS AFI/SAFIs.

BESS is updating RFC9252.
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/__;!!NEt6yMaO-gk!CvENScMlgABx0XQP4W5ctLi1eO0bogKqwoV3FBl6fsZmnZrSIkLbWle6Q6HbZxmxehQfmrQKHgA$>


Should we make this draft an PS or include the changes in the BESS draft?

This document has enough implementations to make it easy to swap to
PS.

We’ll have to do a 1-2 week WG change call.

Sue


=======================
[Idr] Re: AD preliminary review of draft-ietf-idr-ts-flowspec-srv6-policy-04
John Scudder <[e-mail]<mailto:[e-mail]>> Tue, 29 October 2024 16:31 UTCShow header<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/Ym-sK8OXVXXdPEKw9i6jkqbag9A/__;!!NEt6yMaO-gk!CvENScMlgABx0XQP4W5ctLi1eO0bogKqwoV3FBl6fsZmnZrSIkLbWle6Q6HbZxmxehQfTFZs4K4$>
On reflection, I do have a deeper concern about both the Informational status of the document, and the amount of specificity. This document leans on Prefix-SID. Looking at RFC 8669 where Prefix-SID is defined, I see,

```
The BGP Prefix-SID attribute defined in this document can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC4760<https://www.rfc-editor.org/rfc/rfc8669.html#RFC4760><https://urldefense.com/v3/__http://rfc4760*3Chttps/www.rfc-editor.org/rfc/rfc8669.html*RFC4760*3E__;JSMl!!NEt6yMaO-gk!CvENScMlgABx0XQP4W5ctLi1eO0bogKqwoV3FBl6fsZmnZrSIkLbWle6Q6HbZxmxehQfwsLfRTo$>] [RFC8277<https://www.rfc-editor.org/rfc/rfc8669.html#RFC8277><https://urldefense.com/v3/__http://rfc8277*3Chttps/www.rfc-editor.org/rfc/rfc8669.html*RFC8277*3E__;JSMl!!NEt6yMaO-gk!CvENScMlgABx0XQP4W5ctLi1eO0bogKqwoV3FBl6fsZmnZrSIkLbWle6Q6HbZxmxehQfQnDwpmY$>] Usage of the BGP Prefix-SID attribute for other Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be specified in future specifications.
```

This document attaches Prefix-SID to routes of a “not defined herein” family (SAFI 133), but falls short of “specifying” the use and semantics.

To me, that undermines the case for Informational. I’d be interested in discussion of this point before we proceed further.

Thanks,

—John

On Oct 28, 2024, at 3:42 PM, John Scudder <[e-mail]><mailto:&lt;[e-mail]&gt;> wrote:

Hi Authors, Shepherd, WG,

I just made an initial read-through of this draft. In reading the shepherd writeup [1], I see that there was a WG discussion of whether the doc should be Informational or Standards Track:

```
One question asked: Should this be standards document?
The IDR shepherd/chair will consult AD to determine whether this is an
informational or Standards document. That being said, IDR Chairs/Shepherd does
believe this draft is an informational document.
```

In reading through the document, I do agree it’s not ready for publication as Standards Track, and if the WG has consensus to publish it as Informational I’m OK with that, with caveats detailed below. I suppose the rationale for publishing as Informational is that it is a recipe for using pre-existing BGP functions to accomplish the task, and that it doesn’t need to define any new functions, messages, etc. Even so, I am concerned that the draft is so high-level that it wouldn’t be sufficient to enable an implementor to produce an interoperable implementation. This is also called out in the Security Area review [2]:

```
However, as an informational RFC, we wouldn't expect
interoperability will be achieved via this I-D. Given that caveat, the I-D
appears to be ready.
```

I am not quite as relaxed as the Security Area reviewer; normally, I expect any product of the IDR WG to provide enough unambiguous detail to enable an implementor to produce an interoperable implementation. I’m not seeing that. I can see a few ways forward here:

1. Update the draft to supply the needed detail. This will be a non-trivial update, but it would only be a job of filling in missing details, not changing the architecture. If you want to pursue this option, I’ll provide a more detailed review that explains what I think is missing. Even though this is the most work, I think it also would provide the greatest value.

2. Keep the draft as it is, as a high-level overview of the approach. I would accept that if it is the WG’s consensus. If that is the consensus, I would want to make it even clearer that’s what’s being done, though. For example, in the Abstract,

OLD:
This document introduces
the usage of BGP FlowSpec to steer packets into an SR Policy.

NEW:
This document provides a high-level overview of an approach to
using BGP FlowSpec to steer packets into an SR Policy.

Maybe that’s what you were already trying to do with “introduces” but I don’t think that’s unambiguous enough if so.

Note, I am not certain the IESG as a whole will be happy to approve the document if we choose this option. But, if that’s what the WG wants, I’m willing to try.

3. Convince me I am wrong and that the spec as it stands is of sufficient quality to enable interoperable implementations to be written.

Note, I have not checked the mailing list archives in detail, so if there are relevant messages there I should read, please don’t hesitate to refer me to them.

Thanks,

—John

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>