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

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

I have carefully reviewed version 20 of draft-ietf-idr-sdwan-edge-discovery, and the restructured text greatly improves the readability and understandability of the document from my perspective.

There are 2 INT-related issues remaining in the document from my perspective:

  *   In section 3.3.6, when reading the formatting of the sub-TLV, I was first wondering how you could determine whether the local and public IP addresses where IPv4 or IPv6 addresses. Then I began wondering what would be happening if the NAT were a 6to4 NAT. It might be anecdotic, but maybe it would be worth mentioning this case in the document.
  *   In section 4.2.2, the example given is using public IPv4 addresses to document the creation of IPSec Security association over SD-WAN tunnel. The INT area directorate strongly encourages the use of IPv6 addresses from the documentation space in the description of such examples. At least, if IPv4 is still used, it would be preferable to use a private addressing space.

Besides, the text has a number of nits that give the impression that it has not been written with care, and may harm its reception:

  *   In page 1, in the abstract, please introduce the acronyms SD-WAN and NLRI on the first time you are using them.
  *   In page 3, section 1.1, "[SD-WAN-BGP-USAGE] the defines..." - > "[SD-WAN-BGP-USAGE] defines..."
  *   In page 3, section 1.1, "Support for Client Services interfacs on edge..." - > "Support for Client Services interfaces on edge..."
  *   In page 4, section 1.1, "Homogeneous Encripted SD-WAN" - > "Homogeneous Encrypted SD-WAN"
  *   In page 4, section 1.1, "[SD-WAN-BGP-USAGE] provides descriptions on the the use of" - > "[SD-WAN-BGP-USAGE] provides descriptions on the use of..."
  *   In page 5, section 1.3, the text describes the acronym CPE, while, in many parts of the document the acronym C-PE is used. Please make sure to use a consistent acronym along the text (and my preference would go to CPE).
  *   In page 5, section 1.3, "RR:  Route Reflector [RFC4456" - > "RR:  Route Reflector [RFC4456]"
  *   In page 6, section 2, "..the overall solution parts based on the a reference diagram shown.." - > "..the overall solution parts based on the reference diagram shown.."
  *   In page 6, section 2, "...example Topologies..." - > "...example topologies..."
  *   In page 4, section 2.1, "... The SD-WAN Secure L3VPN requires the L3VPN for IPv4 [RFC4364] and IPv6 [RFC4659] be expanded..." - > "... The SD-WAN Secure L3VPN requires the L3VPN for IPv4 [RFC4364] and IPv6 [RFC4659] to  be expanded..."
  *   In page 7, section 2.2.1, "Homogeneous Encripted SD-WAN" - > "Homogeneous Encrypted SD-WAN"
  *   In page 8, section 2.2.1, "sending the approprite traffic" - > "sending the appropriate traffic"
  *   In page 10, section 2.2.1, Figure 2 needs to be reworked so that the boxes and links are properly aligned.
  *   In page 13, section 2.3, "Like any VPN networks," - > "Like any VPN network," (2 times)
  *   In page 14, section 2.4, The example is not clear, since some links in figure 2 are not present in figure 1 (like the link between CPE1 and CPE4, for instance)
  *   In page 14, section 2.4, "The Unsecure Link (P3" - > the sentence seems to finish abruptly.
  *   In page 15, section 2.4, "This simple examples show the" - > "This simple example shows the"
  *   In page 16, section 2.5, "-  transform set." - > "-  Transform set."
  *   In page 17, section 2.6, "(bottomn)" - > "(bottom)"
  *   In page 17, section 2.6, "same topology as a the virtual" - > "same topology as the virtual"
  *   In page 17, section 2.6, "For example, in the picture below," - > Can you be more specific about the figure you refer to?
  *   In page 20, section 3.1, "over a set links" - > "over a set of links"
  *   In page 20, section 3.1, "links may or may not need encryptions." - > "links may or may not need encryption."
  *   In page 21, section 3.1, "the TEA form of the Hyrid SD-WAN Tunnel TLV depend whether the" - > "the TEA form of the Hybrid SD-WAN Tunnel TLV depends on whether the"
  *   In page 23, section 3.1, "Precdence between Color" - > "Precedence between Color"
  *   In page 24, section 3.1, "Encoding and mechanisms are defined 3.3.6.  Section 3.6" - > The sentence is not clear.
  *   In page 24, section 3.2, "with a the SD-WAN Underlay" - > "with a SD-WAN Underlay"
  *   In page 24, section 3.2, "The TEA can include with SubTLVs for" - > "The TEA can include SubTLVs for"
  *   In page 24, section 3.2.1, Figure 8 is not using a consistent formatting with Figures 5 and 6
  *   In page 25, section 3.2.1, Figure 9 is not using a consistent formatting with Figures 5 and 6. Besides fields of lengths 2 or 4 octets are represented in the same way, which looks odd.
  *   In page 28, section 3.3.1, the "IPsec SA Identifier #n" field in Figure 11 is not properly aligned (see last "|"). Besides, the length field displayed in the schema is not the same as the length field described in the text (6 bits vs. 8 bits)
  *   In page 29, section 3.3.1, "the IPSec-SA provide the security" - > "the IPSec-SA provides the security"
  *   In page 29, section 3.3.2, "The encoding iss shown in the figure below:" - > "The encoding is shown in the figure below:"
  *   In page 30, section 3.3.2, the length field displayed in the schema is not the same as the length field described in the text (6 bits vs. 8 bits).
  *   In page 31, section 3.3.2, "IPsec SA Identifier (IPSec-SA-ID):" - > It would be interesting to put the length in bits of the field.
  *   In page 31, section 3.3.3, "The encoding iss shown in the figure below:" - > "The encoding is shown in the figure below:"
  *   In page 32, section 3.3.3, the length field displayed in the schema is not the same as the length field described in the text (6 bits vs. 8 bits).
  *   In page 32, section 3.3.3, "The IPsec SA Rekey SubTLV not help" - > "The IPsec SA Rekey SubTLV does not help"
  *   In page 33, section 3.3.4, "The encoding iss shown in the figure below:" - > "The encoding is shown in the figure below:"
  *   In page 33, section 3.3.4, is the Transform Attr Length necessary?
  *   In page 34, section 3.3.4, "The procedures for" - > "The procedure for"
  *   In page 34, section 3.3.5, in Figure 15, the second line of the header should not be in the figure.
  *   In page 36, section 3.3.5, "A Simplified IPsec SA Sub-TLVis a MALFORMED" - > "A Simplified IPsec SA Sub-TLV is a MALFORMED"
  *   In page 36, section 3.3.6, "Provides information related IPsec and NATs" - > "Provides information related to IPsec and NATs"
  *   In page 37, section 3.3.6, the descriptions of the header fields is not formatted in the same way as in the previous sections.
  *   In page 42, section 3.4.1, "validation in section 6, 8, and 13 applied to the NextHop." - > "validation in sections 6, 8, and 13 applied to the NextHop."
  *   In page 45, section 3.5.2.2, "Subsequent subTLV ware ignored and not propagated." - > "Subsequent subTLV are ignored and not propagated."
  *   In page 46, section 3.6.1, "The SD-WAN client routes associates some of" - > "The SD-WAN client routes associate some of"
  *   In page 47, section 3.6.1, "Invalid tunnel type must be treat if the TLV was not present." - > "Invalid tunnel type must be treated if the TLV was not present."
  *   In page 47, section 3.6.1, ", but propogated." - > ", but propagated."
  *   In page 47, section 3.6.1, "For SD-WAN NLRI underlay routes, the the Extended Port subTLV" - > "For SD-WAN NLRI underlay routes, the Extended Port subTLV"
  *   In page 47, section 3.6.1, "If multiple instancs of the IPsec nonce," - > "If multiple instances of the IPsec nonce,"
  *   In page 48, section 3.6.2, "reception of an type value outside" - > "reception of a type value outside"
  *   In page 48, section 3.6.2, "Local configuration and policy must be carefully constrain" - > "Local configuration and policy must carefully constrain"
  *   In page 48, section 3.6.2, "IPsec security associations in to create a" - > "IPsec security associations to create a"
  *   In page 48, section 3.6.2, "The SD-WAN NLRI should not be paired with Encapsulation Extended" - > "The SD-WAN NLRI should not be paired with an Encapsulation Extended"
  *   In page 48, section 3.6.2, "If an SD-WAN NLRI is paried Encapsulation Extended" - > "If an SD-WAN NLRI is paired with and Encapsulation Extended"
  *   In page 49, section 4.1, "It is critical that the Hybrid SD-WAN Tunnel have correctly forward traffic" - > "It is critical that the Hybrid SD-WAN Tunnel correctly forwards traffic"
  *   In page 49, section 4.2, "IPsec mechansims require" - > "IPsec mechanisms require"
  *   In page 50, section 4.2.1, "The BGP Peer's need to send the IPSec" - > "The BGP Peer needs to send the IPSec"

Best regards,

Antoine Fressancourt


From: Antoine FRESSANCOURT <antoine.fressancourt=[e-mail]>
Sent: jeudi 16 janvier 2025 09:15
To: Susan Hares <[e-mail]>; Antoine FRESSANCOURT <[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 Susan,

Sorry for my delay in answering. I will review the changes you have made by the end of this week, and answer you about those changes.

Best regards,

Antoine Fressancourt

From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Sent: mercredi 15 janvier 2025 20:36
To: Antoine FRESSANCOURT <antoine.fressancourt=[e-mail]<mailto:antoine.fressancourt=[e-mail]>>; Antoine Fressancourt <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>
Subject: RE: Intdir early review of draft-ietf-idr-sdwan-edge-discovery-17

Antoine:

Thank you again for your excellent review of draft-ietf-idr-sdwan-edge-discovery-17.  I believe that the revisions in -20 of the draft address all your concerns.

Would you please review draft-ietf-idr-sdwan-edge-discovery-20.

Thank you,

Susan Hares

From: Antoine FRESSANCOURT <antoine.fressancourt=[e-mail]<mailto:antoine.fressancourt=[e-mail]>>
Sent: Wednesday, November 20, 2024 10:26 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; Antoine Fressancourt <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[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 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.



----







[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.



----







[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.



----







[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