[Int-dir] Re: Intdir early review of draft-ietf-idr-sdwan-edge-discovery-17

[Susan Hares <[e-mail]>]

Antoine:

I want to thank you again for your detailed review.  It helped me decide to rewrite the document instead of limping along with the fractured text.

You should find -19 at:
https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/

Some clean-up issues for the RTG-DIR require -20, so I'd like your feedback on the rewrite.    Your DISCUSS level issues and Technical questions are listed below.  See [Sue-3] for answers.

I plan to add the following if you approved:

  1.  definition of authorized BGP peers in section 1.3  (see DISCUSS-2)
  2.  Some comment that underscores that this implementation is only for walled gardens (see DISCUSS-5)


I also tried to edit the NITs, but I missed the following NITS.  These will be addressed in -20.

  1.  Encaps-EC - should be Encap-EC
  2.  * In page 14, section 5.4, "the" is missing in "An SD-WAN VPN ID is same as a client VPN...". - missed
  3.  * In page 14, section 6, a verb is missing in "The hybrid SD-WAN underlay tunnel UPDATE is to advertise the detailed..." - missed
  4.  3rd paragraph in section 11 (Security Considerations) - noted as your page 34, section 11


I've released a -19 with the rewrite, but there are open issues:


  1.  RTG-DIR open issues - that need feedback from implementers.



Section 3.2.2 - There are open issues regarding the interaction between BGP Update Next Hop, Tunnel Encapsulation Egress Endpoint, and the SD-WAN-Node ID.

Due to IDR's rule about implementations, I need to check with the implementers to see what checks are implemented.  At a high level, the BGP Peer originating should be the BGP Update Next Hop for the Update message and the SD-WAN-Node ID.   The Tunnel Egress must be loosely associated with the Port-Local-ID.


Section 3.2 or 3.2.3 - I need to indicate what optional BGP attributes can be associated with the SD-WAN Underly NLRI.


  1.  SEC-DIR - I need to add 2 new abbreviations (IPsec SA and SA) plus a pointer in the Security considerations.
  2.  OPS-DIR  - No additional fixes.
Sue

From: Antoine FRESSANCOURT <antoine.fressancourt=[e-mail]>
Sent: Wednesday, November 20, 2024 10:26 AM
To: Susan Hares <[e-mail]>; Antoine Fressancourt <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; John Scudder <[e-mail]>
Subject: RE: Intdir early review of draft-ietf-idr-sdwan-edge-discovery-17

Hello, Thanks for your answers to the comments I made in the review of the document. I will answer some requests for clarification and discuss some of your answers inline with the text of your previou
External (antoine.fressancourt=[e-mail]<mailto:antoine.fressancourt=[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzJjZmMxY2UzYWMzNTllMTY0M2NhNmE5MTVmYzMyMjEyLzE3MzIxMTYzNjAuNzc0ODk3Ng==#key=89c6e5ccb71689322eae2a3c356f1e3f>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


Hello,



Thanks for your answers to the comments I made in the review of the document.



I will answer some requests for clarification and discuss some of your answers inline with the text of your previous message. My comments and answers are prefixed with [AFT]. I stripped some text that was not necessary to understand the discussion from this answer.



Best regards,

--

Antoine



[....]





[Discuss-1]

* In section 3.3.1, two types of encoding for the Client Route UPDATE messages are given, "Barebones" and Tunnel Encaps Attribute, while they are described only in section 5.



[Sue:]  RFC9012 defines two forms of a Tunnel Encapsulation attribute:

1: An Extended Community with just the Tunnel ID defined in RFC9012 as "Barebones",

2: a Tunnel Encapsulation Attribute.

So, are you asking for these definitions to be reiterated in the definitions?



[AFT]

In the text, I think that the one paragraph description that basically states what you write in your answer should be placed before the first use or presentation of BGP messages using either encoding. A more detailed description can be avoided with a reference to RFC 9012, but for the sake of clarity, I think positioning this simplified definition before section 3.3.1 is better.



[Sue-3]: I have placed additional text on page 17 (pdf) in the section 3.1 in the heading "Encoding:".  Is this enough?



[Discuss-2]

* In section 3.4, the behavior of the RR mentions authorized BGP peers, but the document does not give an idea about where and how those authorized BGP peers are set.



[Sue:]  Most BGP drafts concerning RR authorized peers assume local configuration specifies  1.  peer address, and b) some secure link.  Are you asking that "authorized BGP peers" be defined prior to the use of the term in section 3.4.



[AFT]

Providing the explanation you give as an answer to this point in the text would make the text clearer in my view. Besides, if this behavior is clearly explained in another document, I think it would be interesting to point to this document as an informative reference.



[Sue-3]:  Section 1.0 has been rewritten to reestablish the link from draft-ietf-idr-sdwan-edge-discovery-19 to draft-ietf-bess-sdwan-usage.

Section 2.2 has been rewritten to provide the high-level logical example of the mechanisms. Within section 2.2, section 2.2.3 paragraph 2 indicates that existing BGP Update mechanism control how RRs distribute routes.  Section 2.2.4, provides a logical example where we state "RR Policy".  Section 2.6 applies this to SD-WAN segmentation.  These descriptions come before the mechanisms in section 3.   Should I add the term "authorized BGP peers" in the definitions.  What do you think?



[Discuss-3]

 * In section 4.2, the text mentions that the RR speaks to the BGP clients over

IPSec while section 3.4 mentions a secure transport session (e.g. TLS)



Sue: BGP works over Transport layer.  Contrary to the actual specification many implementations use TLS or TCP over IP-SEC  or other means of securing the text.  Would adding this level of detail to section 3.4 resolve this "DISCUSS" level issue?

 Or are you looking for something else?



[AFT]

My remark stems from an inconsistency between the text in sections 3.4 and 4.2. For the sake of clarifying, I think that you should clearly state the assumptions you are making about the security and integrity of the channel you are using to convey the BGP messages, and point to the documents describing the secure transport mechanisms you would use.



[Sue-3:] Section 1.0, paragraph 2 states the assumption of a secure connection between RR and each BGP Peer supporting SD-WAN.  This paragraph states the establishment of the secure channel is outside the scope of the document.   Section 2-4 have been rewritten into a single section (section 2) and references to MEF[70.1], MEF[70.2], and draft-ietf-bess-sdwan-usage-25.  In section 2, Figures 2 and 3 reiterate that the BGP connections to the RR are over secure links or secure transports.   In the new section 2, sections 2.2.3 and 2.6 try to resolve the RR secure transport.



----



[Discuss-4]

* In section 8, the text refers to the IPSec-SA-ID, and assumes it has been set but very little details are given in the document as to how this ID is set, negotiated or provisioned in the IPSec SA endpoints. References are made to other RFCs, but the text would benefit from a description of the mechanism the authors are considering using.



[Sue-2]   First of all, BGP is not setting up the IPsec tunnel.  It is only passing parameters so the tunnel can be set-up.   Second, if it is helpful to provide a description of the mechanism, it can be added.  However, it seems you have something in mind.  Would you mind providing 4 bullet points on what you'd like added.



[AFT]

The only thing I have in mind is the objective to make the document's text clear enough to allow implementers to develop interoperable implementations



[Sue-3]: All section relating to IPsec SA SubTLVs  have been reformatted with a new format that I am proposing (as IDR co-chair) for all BGP Tunnel-encapsulation Attributes.  We have two interoperable implementations of this technology since IDR requires 2 implementations.   We have also discussed a third company switching to this format from their proprietary form.



[Discuss -5]

* In section 11, the text describes "walled garden SD-WAN deployments" but does not state the differences with a more open SD-WAN deployment.

[Sue-3]: There is no plan for "more open" SD-WAN deployments of Secure SD-WAN L3VPN and Secure SD-WAN Links.

The Secure EVPN document  (draft-ietf-bess-secure-evpn-02) discusses this point, but it is not directly linked with SD-WAN.



[Discuss-6]

In general, the document tends to give the detail of the formatting used in the messages and TLVs before describing the protocol mechanism using those

messages. The general understanding of the protocol's mechanism would be improved if this were done the other way round.

[Sue-3]:  RTG-DIR wanted: general description  of protocol mechanisms (section 2), detail of formatting (section 3.1 - 3.3) and details on protocol mechanisms (section 3.4-3.6).  This rewrite follows that document.  Please let me know if this resolves your discuss-6.



[Technical question-1]

* In section 6.1 about the SD-WAN NLRI, it is mentioned that "Route type outside of 1 are out of scope for this document": Are other route types used in

private or experimental deployments? What is the justification for using 2 bytes to carry a route type that is associated a single value in the document's context?



[Sue-3] Let give you a bit more of the background on why we are allowing a different route type.  First let me start with links to existing WG work:

  *   draft-ietf-rtgwg-multisegment-sdwan-01 specifies a changes to the GENEVE header for SDWAN multiple segments.
  *   EVPN uses the Tunnel Encapsulation Attribute (TEA) in BGP to pass the Geneve header information (draft-ietf-bess-evpn-geneve-08).
  *   The EVPN usage of TEA is not fully specified (P.S. I am the IDR co-chair that reviews all TEA drafts).
  *   The Geneve is one encapsulation that might be used within the SD-WAN hybrid tunnel as it bundles tunnel.
  *   It is unclear if the Route-1 format would handle the EVPN with Geneve case.
  *   The work is on-going in IDR, BESS and RTGWG.



[Technical questions 2 (bundled) ]:

* In section 7 about the Extended port attribute TLV, 1 byte is dedicated to both the NAT type and the Encap type to encode 7 and 2 possibilities while the transport network ID and the Routing Domain ID need to be globally unique, which requires space: wouldn't it be possible to reallocate some space from the 2 first fields to give more space to the two later fields?



* In the same section, is it always necessary to carry the Public IP and Public port fields? Can a flag be used to signal the presence of those two fields if necessary?



* In section 7.1.1, in the design of the Underlay Network Transport subsubTLV, why are the connection and port type described rather than their underlying

properties (bandwidth, cost, latency, jitter, packet loss...)? Describing the underlay link's characteristics in a more abstract way could help the TLV be

more generic.



[Sue-3]: One my co-authors reached out to the implementers with your comments.  The implementers agreed they could be more efficient, but the code is deployed.  The implementers may propose new TLV that is more efficient.  However, the current code is deployed.



[IDR chair hat on]: Due to IDR's requirement for implementation and fielding, we do allow for revision and deprecation of the TLVs.

[IDR chair hat off];



* In section 8.5 about the simplified IPSec SA sub-TLV, is it necessary to allocate a full byte to both the Transform and the IPSec mode fields?



[Sue-3]: One my co-authors reached out to the implementers with your comments.  Again, the TLV could be more efficient, but it is deployed.



[Should]

The following are other issues I found with this document that SHOULD be

corrected before publication:



[Should-1]

It is to be noted that Figure 1 extensively uses public IP(v4) addresses.

Proper private addresses should be used for the addresses in the SD-WAN realm,

while public underlay addresses should be clearly marked as example addresses

not to be reused in public deployments



[sue-3]: Section 2 and figure 1 has been rewritten to use logical addresses.



[NIT-comments]

"[MP_REACH_NLRI] - has been removed.

[MEF-70.1] and [MEF70.2] have been added.



NIT Comments related to section 3 and 4 - have bene rewritten.



* In page 6, section 3.3.1, is "[Encap-EC]" a reference to a document, or a

specific section to a document?