Hi Linda,
Looking at the diff between versions 20 and 22 I continue to have concerns.
I don’t think I’ve gotten much in the way of responses to my first and second
points, but to a large extent, these are for the AD and WG chairs; they can
redirect back to the authors as needed, but let’s not focus on them right now.
The third and fourth points are squarely in the authors’ court.
Regarding my third DISCUSS point, about Section 5.2, in your revised version
you’ve added,
Note: The IPsec Tunnel Type specified in RFC5566 is obsolete. A
new tunnel type is needed to represent the IPsec Tunnel underlay
path.
I don’t think it’s a good idea for us to be publishing RFCs that are
effectively obsolete on delivery. If a new tunnel type is needed, then that
work should be done before you publish a solution that depends on it! For that
matter, Section 5.3 in the revision now has,
UPDATE #1a for the client prefix 192.0.2.4/30:
- MP-NLRI Path Attribute:
192.0.2.4/30
Nexthop: 192.0.2.2 (C-PE2)
- Encapsulation Extended Community: TYPE = IPsec
- Color Extended Community: RED
Which has the same problem (but no disclaimer). It also recurs in Section 5.4,
unchanged from the previous versions.
There’s also a second problem, which is more critical than the (already
serious) problem of using an obsolete type in a new RFC. That is, you don’t say
anywhere what the intended *semantics* of the "Encapsulation Extended
Community: TYPE = IPsec” are. What I understood (but I might be wrong) from our
previous conversation is that it’s intended as a hint that when resolving the
client route, if there are multiple tunnel types associated with 192.0.2.2,
then the IPsec tunnel type should be preferred. As we discussed previously, I
don’t think this is needed, RFC 9012 already has all the machinery you need
using Color Extended Community. (Keep in mind that a thing can have more than
one Color Extended Community associated with it.)
While I don’t insist that you follow the approach I suggest, I do think the
spec has to be clear about what the "Encapsulation Extended Community: TYPE =
IPsec” (or its replacement) is *for*, since it’s clearly *not* for what RFC
9012 documents the semantics of an Encapsulation Extended Community to be.
Right now, this is left up to the imagination of the reader. Leaving things to
the imagination of the reader is the opposite of what an RFC should do.
Regarding my fourth DISCUSS point, about Section 3.1.5, my understanding from
our conversation is that the security model is based on route reflectors having
configured (possibly by a management system of course) policy that controls
what PEs are allowed to receive what routes. Here’s your updated paragraph that
makes it more explicit (thank you):
BGP is well suited for this purpose. RFC4684 has specified the
procedure to constrain the distribution of BGP UPDATE to only a
subset of nodes. Route-Reflector (RR) [RFC4456], as an integral
part of the SD-WAN controller, has the policy governing
communication among peers. The RR only propagates the BGP UPDATE
from an edge to others within the same SD-WAN VPN.
I continue to wonder why you need RFC 4684 at all, given that you’re telling me
that the “Route-Reflectors… has the policy governing communication among
peers”, that is, it already *knows* where the routes are supposed to go, so why
does it need RFC 4684 to tell it?
Also, irrespective of the details of the above, I think the Security
Considerations section deserves to have a clearer description of the security
model, instead of having it only embedded in the middle of Section 3.1.5. (My
understanding with the revised text, is that all security properties depend on
the correct configuration and operation of the route reflectors. Which is fine,
but shouldn’t you say so?)
Regards,
—John
> On Apr 5, 2024, at 5:49 PM, Linda Dunbar <linda.dun...@futurewei.com> wrote:
>
> John,
>
> Thank you very much for spending time with us during IETF 119 explaining your
> concerns of the draft.
>
> We have revised the draft that addressed all the comments and suggestions
> from the IESG LC comments and discussion during the IETF119 meeting.
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/__;!!NEt6yMaO-gk!Aig25lrJiALWg7GcYb1GZy4Gv6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu37Ii0qmA$
> Can you please review and let us know if the draft can be moved forward to
> RFC?
>
> This document describes the SD-WAN use cases, which explain why WAN port
> advertisements for the underlay path and client prefix advertisements need to
> be separated and illustrate how the BGP-based control plane can effectively
> manage large-scale SD-WAN overlay networks with minimal manual intervention.
>
> Thank you very much,
> Linda
>
> -----Original Message-----
> From: John Scudder <j...@juniper.net>
> Sent: Wednesday, February 28, 2024 9:05 AM
> To: Linda Dunbar <linda.dun...@futurewei.com>
> Cc: The IESG <i...@ietf.org>; draft-ietf-bess-bgp-sdwan-us...@ietf.org;
> bess-cha...@ietf.org; bess@ietf.org; matthew.bo...@nokia.com
> Subject: Re: John Scudder's Discuss on draft-ietf-bess-bgp-sdwan-usage-20:
> (with DISCUSS and COMMENT)
>
> Hi Linda,
>
> A few replies to some of the more specific/actionable points, below.
>
>> On Feb 27, 2024, at 10:47 PM, Linda Dunbar <linda.dun...@futurewei.com>
>> wrote:
> ...
>> ### Error in how RFC 9012 is used
>>
>> In Section 5.2, the Encapsulation Extended Community is misused. See
>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmail__;JSUl!!NEt6yMaO-gk!Aig25lrJiALWg7GcYb1GZy4Gv6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu3Ofo47_s$
>> archive.ietf.org%2Farch%2Fmsg%2Fidr%2FumBB5yfoC3mFMpIWIT2K8159Gos%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cb65cbbac81144d1fbb1808dc386ead26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638447295225231753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CKLRVL8ylb5Ey6U3cmYMo2A%2FsmtBpLj8Ir%2BQ9Oq%2FwFU%3D&reserved=0
>> for related explanation of the error. The error recurs in Sections 5.3 and
>> 5.4.
>>
>> [Linda] Please see the discussions related to the topic. For SD-WAN
>> scenario, simple NextHop is not enough for client routes advertisement
>> because different client routes need to be forwarded by different underlay
>> paths. It is not practical to include all the information about the underlay
>> path with the client routes advertisement.
>
> To paraphrase my reply to the other thread linked above, just because you
> want a nail, that doesn't mean Encapsulation Extended Community is a nail. In
> that last reply, I suggested a few other mechanisms you could use, but if you
> think you must have some kind of tunnel affinity indicator that isn’t color,
> you can specify one, there are plenty of unused extended community code
> points available. But Encapsulation Extended Community has already been
> specified and does not have the semantics you want.
>
> (As an aside, anywhere you’re referencing a code point, if you’re not using
> the exact name found in the IANA registry, please mention the numeric value
> also.)
>
>> Also, there is no such thing as “TYPE = IPsec” (referenced in
>> Sections 5.2 and 5.4), see
>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!Aig25lrJiALWg7GcYb1GZy4Gv6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu37FMbm5A$
>> .
>> iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsu
>> lation.xhtml%23tunnel-types&data=05%7C02%7Clinda.dunbar%40futurewei.co
>> m%7Cb65cbbac81144d1fbb1808dc386ead26%7C0fee8ff2a3b240189c753a1d5591fed
>> c%7C1%7C0%7C638447295225239072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
>> =qrDlj1%2F2jHbhRd2G40zQMNybiwzNz3iN%2FBkrJ78grew%3D&reserved=0
>>
>> [Linda] RFC5566 has specified IPsec Tunnel Type (IPsec in Tunnel-mode:
>> Tunnel Type = 4 [RFC4302], [RFC4303]). We can add the reference.
>
> RFC 5566 status is Obsolete, Tunnel Type = 4 status is Deprecated (that’s why
> I put the link to the registry there, in part). I don’t think we should be
> publishing new RFCs with normative references to Obsolete RFCs and Deprecated
> code points.
>
>> This one should be straightforward to fix. It does lead me to be
>> worried about the level of review the document has received, though.
>>
>> ### Section 3.1.5, security model
>> BGP is well suited for this purpose. RFC4684 has specified the
>> procedure to constrain the distribution of BGP UPDATE to only a
>> subset of nodes. Each edge node informs the Route-Reflector (RR)
>> [RFC4456] on its interested SD-WAN VPNs. The RR only propagates
>> the BGP UPDATE from an edge to others within the same SD-WAN VPN.
>>
>> RFC 4684 is driven by demand -- a PE will advertise RT membership
>> NLRI to "request" that it receive routes with the given RT. So, this
>> means the security model is that the client router is implicitly
>> trusted to declare its VPN
>> membership(s) truthfully and accurately. I don't see this addressed in
>> the Security Considerations.
>>
>> [Linda] Section 3.2 states that the SD-WAN Local Network Controller, e.g.,
>> RR in BGP-controlled SD-WAN, is managing the policy governing communication
>> among peers.
>>
>> Here is the wording added in Section 3.1.5 to address your concern:
>> “Route-Reflector (RR) [RFC4456], as an integral part of the SD-WAN
>> controller, has the policy governing communication among peers. The RR only
>> propagates the BGP UPDATE from an edge to its authorized peers.”
>
> If the RR has to be explicitly configured to police all propagation of
> routes, instead of trusting RT membership NLRI… what value does RFC 4684
> bring? You’re already requiring that the distribution topology be
> comprehensively configured.
>
> (As an aside, no BGP speaker “propagates BGP UPDATE” messages, that’s not a
> thing, the closest we get in our standards is BMP Route Mirroring mode, but
> that’s not applicable here. What you mean is that the RR only propagates BGP
> routes from an edge to its authorized peers.)
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ———————————————————————————————————
> ...
>> [Linda] The term “Client Route” is adopted from the RFC4364. In this
>> document, client route means the prefixes attached to the client ports of an
>> SD-WAN edge. Add this to the Terminology section.
>
> I don’t see “client route” in RFC 4364, but if you’ve added a definition
> that’s fine.
>
> ...
>> What anti-DDoS mechanism is that? None is specified here, nor referenced.
>>
>> [Linda] anti-DDoS is a commonly used tool for any interface facing ports. It
>> is out of the scope of this document to describe the details. Is adding the
>> following sentence helpful?
>> “The anti-DDoS mechanism comprises numerous components, and their
>> detailed discussion is beyond the scope of this document.”
>
> Not helpful to me — if it’s a commonly used tool, surely there might be some
> reference available for it. But I see Roman has raised this point too, I’ll
> defer to him for further discussion of it.
>
>> ### Figure 7
>>
>> Figure 7 is mangled to the point of being unreadable.
>>
>> [Linda] Figure 7 is to show underlay paths can be via trusted VPN and
>> “untrusted network”. Over the “Untrusted Network”, packets have to be
>> encrypted. We greatly appreciate any suggestion to make it better. The
>> intent is to demonstrate some traffic have to be forwarded via trusted VPN,
>> while other traffic can be forwarded via either untrusted network (with
>> encryption) or trusted VPN.
>
> I literally mean that the lines and boxes and such don’t line up, there are
> boxes without labels, etc. It looks like the ASCII-art got trashed in version
> 16, so my suggestion would be to revert to what was in version 15 as “figure
> 8”. Even that version is a little funky — is it really your intent that there
> be no connection between A3 and the adjacent PE? Seems like it couldn’t
> possibly be, since as currently pictured C-PE-a has no connection to the
> trusted VPN and therefore isn’t actually illustrating “hybrid”. So probably
> add that arc too.
>
> —John
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
