[Idr] draft-ietf-idr-tunnel-encaps-10: Should add IPsec & IPsec-GRE as valid Tunnel Types

[Linda Dunbar <[e-mail]>]

Eric and authors of draft-ietf-idr-tunnel-encaps-10:

Section 3.2 listed VXLAN, VXLAN-GRE, NVGRE, L2TPV3, GRE, MPLS-in-GRE as Tunnel Types.

For some deployment scenarios, two nodes can also have ports facing Internet, which requires IPsec to encapsulate the traffic as shown in the following diagram (described in https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ ):

[cid:image002.png@01D4B33D.C5AD6880]

Can your section 3.2 add IPsec & IPsec-GRE as valid Tunnel Types?
If you don't think IPsec Tunnel Types should be added, can you explain why?

If Yes, should the "Remote Endpoint Sub-TLV" use the remote Interface (port) addresses (i.e. B1, B2, etc)?  or should the "Remote Endpoint Sub-TLV" use the PE2's loopback address of 10.1.2.1?

On Page 25 (Section 5), you have a sentence stating:
"Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used for carrying data."

This is applicable to IPsec tunnel that requires explicit setup protocol, correct?


In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3):
[cid:image006.jpg@01D4B33D.C5AD6880]


How does draft-ietf-idr-tunnel-encaps-10 indicate the Tunnel originating interface?

In the Figure above, there are at least 3 tunnels between PE1 <->PE2: T1 (via MPLS), T2 and T3 via IPsec over internet. For a Prefix X reachable via PE2, does PE1 send BGP Update for Prefix X with 3 different Tunnel Encap attributes to all its neighbors?  Say PE4?  Those Tunnel information is really between PE1<->P2, other nodes, e.g. PE4 really doesn't need to know, correct?


Thank you very much for the help.
Linda Dunbar