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

[Linda Dunbar <[e-mail]>]

John,

Thank you very much for the explanation.

More questions are inserted below:

-----Original Message-----
[Snipped]

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

[Linda] That is a very good point. I am just curious if all other TLVs/subTLVs of BGP's UPDATEs must be present with value NULL (0) to emphasize that it is not accidently 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.
[Linda] simply a shorter message body, not sure if it is compelling enough.


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

[Linda] Your statement is indeed much clearer. Thank you. When a Node-A constructs this Tunnel-Encap UPDATE for routes attached to Node-A, does it use its own address in the  “UPDATE’s Network Address of Next Hop field”?  Does it have the options of using Node-A’s “Loopback address”, or the address of one of the ports on Node-A’s ?
If another node, say Node-B constructs this Tunnel-Encap UPDATE on behalf of Node-A, will the address in the  “UPDATE’s Network Address of Next Hop field” same as the Node-A address?
Under what scenarios, the address in “Remote endpoint sub-TLV” is different from the ““UPDATE’s Network Address of Next Hop field”?

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.
[Linda] Isn’t the Source Address of the UPDATE message same as the originating node of the UPDATE message?

Thanks,

—John