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

[Antoine FRESSANCOURT <[e-mail]>]

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]>
Sent: mercredi 15 janvier 2025 20:36
To: Antoine FRESSANCOURT <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

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