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

[Antoine FRESSANCOURT <[e-mail]>]

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.

In that extend, I think adding some text that explains, even at a rather high level, how the information received through BGP are used to set up hybrid IPsec tunnels with peers, and in particular who is setting the IPSec-SA-ID, what it is identifying, what the hybrid tunnel end needs to support and when it learns about it would clarify the text in section 8.

----



[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:] What do you mean by a more open SD-WAN deployment?  Is this a concept from

Internet technology that I'm missing.   The walled garden is created by the BGP configurations which limit the deployment of

the technology.   The description is intended to show the distribution of information by BGP

(see scoping in draft-haas-attribute-escape).  /



[AFT]

Sorry, my remark was not clear. My intention was to say that the way the text is written gave me the feeling that there was other deployment methods compared to the walled garden method you mention in the text. I was not referring to another method. Thinking about it, it might be possible to deploy federated SD-WAN in which peers belonging to collaborating entities would be able to discover one another, but it is far reaching, and beyond the scope of my remark. It would be sufficient to state that, by essence, SD-WAN deployments are considered "walled garden" so the security relies on perimetric security mechanisms used to make the garden's walls solid enough.

----



[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:] The RTG-DIR review strongly encouraged the TLVs before protocol descriptions.  (smile).

Section 3 and 4 were given to provide an overview of the protocol mechanisms .

 Did these section fail to  provide insight on the technology?  The details of the

protocol mechanisms need the specific of the text.



[AFT]

I didn't expect to make explicitly orthogonal comments compared to the RTG-DIR review, but, from my personal perspective, it is easier to understand why some messages are needed, and why they need to carry specific information if I have a sense of the goal behind the message exchange. And I had the feeling that the text in the document was not written following this logic. But maybe this is only my way of describing things, and others have alternative ways of describing things. You may make this remark [Editorial] if needed.

----



[Discuss-7]

On a technical standpoint, I have some questions regarding the design of the

TLVs described in the document:



[Discuss-8]

* 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]:  Three reasons for 2 bytes to carry route type:

  1.  BGP specifications usually try to future proof by allowing easy revisions.

 (IDR WG has had painful lessons since some specifications were not future proofed.

  1.  A Secure VPN  was a proprietary network technology that the authors  are trying to

replace with this standard technology. As such, initial implementations  of this specification

may find they lacked something that the NLRI  format cannot pass.

  1.  2 bytes instead of 1 byte - brings the header to an even number of bytes.

[AFT]
1/ While I sympathize with the goal to design a future proof protocol, we are talking about possibly encoding 65536 different types of routes, which is a lot.
2/ Understood.
3/ Encoding the length over 1 byte can make the header fit in an even number of bytes (but might be inconsistent with RFC4760).
Trying to take a step back from my initial comment, I think that I wouldn't have made the remark if there were a piece of text mentioning that the TLV is following formatting requirements from RFC4760. Besides, I would have added a sentence describing SAFI for the sake of clarity in the document.
----



[Discuss-9]

* 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?



[Sue:] Yes.  A bit of history and context is necessary here.

 IDR only standardizes in a PS what has been implemented.  This form has been implemented.

Newer revision drafts may use better TLV formats.


[AFT]
I understand that this draft documents implementations, but assigning a proper space to IDs that are supposed to be globally unique is necessary otherwise the birthday paradox will strike earlier than expected.
While reading the text again, I think the scope of the global uniqueness of both the Transport Network ID and the RR ID needs to be clarified. Is it global among the networks and domains managed by an administrative entity (a SD-WAN provider), or across entities (multiple SD-WAN providers)?
----



[Discuss-10]

* 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?

[Sue]: See answer above.   IDR only standardizes in a PS what has been implemented.

This form has been implemented. Newer revision drafts may use better TLV formats.


[AFT]
Understood.

----



 [Discuss-11]

* 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]: Again, this TLV has been implemented and deployed.

New TLV mechanisms are in process.


[AFT]
Understood.

----



[Discuss-12]

* 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]: See answer above. It was the first encoding and in implementations.


[AFT]
Understood.

----



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

corrected before publication:



[Technical-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]:  We have conflicting issues between RTG desires and your request.

Let me talk to my AD and this document shepherd regarding this issue.


[AFT]
The INT area policy is to ask draft authors to either provide examples only with IPv6 or with both IPv4 and IPv6 if necessary.
----



=================

[...]



[Editorial-15]

* In page 18, in Figure 11, the content of the Type box is unclear.

[Sue]:  What is unclear?  I will try to clarify



[AFT]

I would replace "|Type=65(extPort|" with "|ExtPort Type (65)|" in the figure in order that the fields descriptors have a similar format across the whole figure.

----



[...]