Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

[John Scudder <[e-mail]>]

(As a WG member. I don’t speak from any authority, other than “a person who has read the spec several times and worked with implementors”.)

> On Jun 26, 2019, at 2:46 PM, Linda Dunbar <[e-mail]> wrote:
> 
> John and the Tunnel-Encap authors:
>  
> The following text on page 9 of Section 3.1 states that Remote sub-TLV can have NULL (0).
>  
> <image002.png>
>  
>  
> It seems to me that this paragraph contradicts to the statement that “Remote sub-TLV” must be present.

I don’t understand how that is a contradiction. A remote address sub-tlv with remote endpoint field value of 0 clearly IS a case of the sub-tlv being present — there is no field to be 0 if the sub-tlv isn’t present! The semantics of the 0 field are well-defined. There seems to be no contradiction to me.

> Why can’t receivers assume the “the tunnel’s remote endpoint is the UPDATE’s BGP next hop” if the remote sub-TLV is not present?

… because the spec doesn’t say that? 

Of course, the spec could (even at this late date) be changed to permit that behavior, but I don’t see it bringing any benefit since those semantics are already defined using remote endpoint = 0. Furthermore, advertising the sub-tlv with remote endpoint = 0 has the merit that it makes it explicit the behavior is desired, vs. having it happen by accident if the sub-tlv is inadvertently omitted.

If you have a compelling case for needing to omit the remote endpoint sub-tlv and get the stated effects, instead of including it with value 0, please do share.
 
> Another question: which of the following interpretation of the above paragraph is correct?
>  “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s remote endpoint is the originating node of the UPDATE message”
> Or 
> “tunnel’s remote endpoint is the UPDATE’s BGP netxt hop” == “tunnel’s remote endpoint is the next hop for the routes indicated in the received UPDATE message”

I think it’s unambiguously the latter, since “BGP next hop” is a term of art. One might say “BGP NEXT_HOP” except that’s not formally correct for MP-BGP, where the right thing would be “value of the Network Address of Next Hop field within the MP_REACH_NLRI attribute”. So the text should either stand as written (my preference) or if great precision is needed, it could say something like “tunnel’s endpoint is the value depicted in either the UPDATE’s Network Address of Next Hop field within the MP_REACH_NLRI attribute if present, or NEXT_HOP attribute otherwise.”

Apart from the plain reading of the text, the other reason I think the first interpretation is not correct is, how is a receiver supposed to know what “the originating node of the UPDATE message” is? Without specified procedures, that relate to fields within the message, it would be ambiguous.

Thanks,

—John