Re: [Idr] Questions to draft-hujun-idr-bgp-ipsec-01

["Hu, Jun (Nokia - US/Mountain View)" <[e-mail]>]

My comments in line

From: Linda Dunbar <[e-mail]>
Sent: Monday, November 18, 2019 9:13 AM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]>; [e-mail]
Cc: 'Paul Wouters' <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; Susan Hares <[e-mail]>
Subject: RE: [Idr] Questions to draft-hujun-idr-bgp-ipsec-01

Jun,
Thank you very much for the answers.  Yes, the questions are to draft-hujun-idr-bgp-ipsec-01.

Here are more questions:

  *   If I want to find the least set of information for a node to propagate for IPsec tunnels to a set of nodes, can I use "Next Hop" field in the MP-NLRI for the Local Tunnel Endpoint? So the Tunnel-Encap Path Attribute doesn't have to include the "Local Tunnel Endpoint Address" subTLV
[Hu Jun] since my draft is just an extension of draft-ietf-idr-tunnel-encaps, so following text in section 3.1 of draft-ietf-idr-tunnel-encaps applies here:

"   There is one special case: the Tunnel Endpoint sub-TLV MAY have a
   value field whose Address Family subfield contains 0.  This means
   that the tunnel's egress endpoint is the UPDATE's BGP next hop.  If
   the Address Family subfield contains 0, the Address subfield is
   omitted, and the Autonomous System number field is set to 0
"

  *   What is the difference between "Private Routing Instance" and "Child SA Traffic" selection? Can they be the same?
[Hu Jun] private routing instance is the same routing instance where NLRI or local/remote prefix sub-TLV belongs to

  *   Can the "Private Routing Instance" be listed as Routes in the MP-NLRI  Path Attribute?
[Hu Jun] private routing instance is not really a route, it is the route target of a MP-NLRI

  *   Under what circumstance that you will need "Public routing instance"?   especially, for a network with set of CPEs in one customer AS running as Overlay and the routing instance is locally significant to the Customer domain.
[Hu Jun] in case where your clear traffic is forwarded in a routing instance different than the encapsulated IPsec traffic is forwarded in; for example, in enterprise VPN use case, the private routing instance could be enterprise's intranet, while encapsulated IPsec packet could be forwarded in public internet

Thank you.

Linda
From: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 18, 2019 8:13 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'Paul Wouters' <[e-mail]<mailto:[e-mail]>>; 'Benjamin Kaduk' <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] Questions to draft-hujun-idr-bgp-ipsec-transport-mode-00.txt

Hi Linda,
I assume your questions are really about draft-hujun-idr-bgp-ipsec-01? since draft-hujun-idr-bgp-ipsec-transport-mode-00 doesn't have figure 4;
"Figure 4: does R1 use Subnet A in NLRI? And have Tunnel-Encap with more detailed description on SubnetA<->SubnetB  & SubnetA<->Subnet C? "
 Yes, R1 will advertise subnet-A in NLRI; not sure I understand your 2nd part of the question, but section 2.1 of draft-hujun-idr-bgp-ipsec-01 defines local/remote prefix sub-TLV (NLRI could be used for local prefix)

"How does R1 need to know that Subnet A and Subnet B needs to communicate ahead of time? "
This depends on use case, in this example, both R1 and R2 belong to same admin domain, so this kind of thing could be planned ahead; in other use case, if the remote prefix is not known or user want same Ipsec config for all remote prefix, then an all-zero prefix could be used in remote prefix sub-TLV


"In addition, if the network has 4 routers, R1, R2, R3 and R4. Does the Update from R1 include all the <Local- Remote> pairs in each single UPDATE?

i.e. when R1 sends out the UPDATE for the Subnet A attached to R1, the UPDATE from R1 has to include
        Local subnet A <-> remote subnet B on R2
Local subnet A <-> remote subnet D on R3
Local subnet A <-> remote subnet F on R4


Is it correct? If there are 100 nodes in the network, the UPDATE message has to include 100 pairs?
"
As explained above, it could be done this way, but not necessary; it really depends on granularity user case needs





From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, November 17, 2019 8:52 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'Paul Wouters' <[e-mail]<mailto:[e-mail]>>; 'Benjamin Kaduk' <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] Questions to draft-hujun-idr-bgp-ipsec-transport-mode-00.txt

Jun,

In addition, if the network has 4 routers, R1, R2, R3 and R4. Does the Update from R1 include all the <Local- Remote> pairs in each single UPDATE?

i.e. when R1 sends out the UPDATE for the Subnet A attached to R1, the UPDATE from R1 has to include
        Local subnet A <-> remote subnet B on R2
Local subnet A <-> remote subnet D on R3
Local subnet A <-> remote subnet F on R4


Is it correct? If there are 100 nodes in the network, the UPDATE message has to include 100 pairs?

Linda

-----Original Message-----
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Linda Dunbar
Sent: Sunday, November 17, 2019 8:32 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'Paul Wouters' <[e-mail]<mailto:[e-mail]>>; 'Benjamin Kaduk' <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] Questions to draft-hujun-idr-bgp-ipsec-transport-mode-00.txt

Jun,

I have some questions on your draft:

Figure 4: does R1 use Subnet A in NLRI? And have Tunnel-Encap with more detailed description on SubnetA<->SubnetB  & SubnetA<->Subnet C?

How does R1 need to know that Subnet A and Subnet B needs to communicate ahead of time?

Linda


-----Original Message-----
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Hu, Jun (Nokia - US/Mountain View)
Sent: Friday, October 11, 2019 6:46 AM
To: [e-mail]<mailto:[e-mail]>
Cc: 'Paul Wouters' <[e-mail]<mailto:[e-mail]>>; 'Benjamin Kaduk' <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] FW: New Version Notification for draft-hujun-idr-bgp-ipsec-transport-mode-00.txt

Hi,
Here is a new draft for using BGP to provision IPsec transport mode protected tunnel config; this draft is in companion with draft-hujun-idr-bgp-ipsec-01 (Ipsec tunnel mode) to provide a complete solution of using BGP provision IPsec config.

Review and comment will be appreciated.

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 10, 2019 3:41 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-hujun-idr-bgp-ipsec-transport-mode-00.txt


A new version of I-D, draft-hujun-idr-bgp-ipsec-transport-mode-00.txt
has been successfully submitted by Hu Jun and posted to the IETF repository.

Name:           draft-hujun-idr-bgp-ipsec-transport-mode
Revision:       00
Title:          BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration
Document date:  2019-10-10
Group:          Individual Submission
Pages:          7
URL:            https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-hujun-idr-bgp-ipsec-transport-mode-00.txt&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488703369&amp;sdata=L%2Bq8Gmm6svj7vUgwQqWCHqx6ex2MefKRN1U58vFwJ%2Fg%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-hujun-idr-bgp-ipsec-transport-mode-00.txt&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822610357&sdata=eOAU9X%2FzfcMoahs%2FotSsufznlK5uN%2FfnurGcGc7aVcg%3D&reserved=0>
Status:         https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488703369&amp;sdata=fdGi7esvdmdejiZQ6s1ZjAauLjdtzETi4BXAC8664Ss%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822610357&sdata=Q%2B7xt%2B2fKBKCUEogNk4FRCprASbiasTwo8UPoJaE6%2FA%3D&reserved=0>
Htmlized:       https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hujun-idr-bgp-ipsec-transport-mode-00&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488703369&amp;sdata=5GCI9uiTuLRbdNSvjT48mpbe1IxTWT8sXPm6qzkRaIE%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hujun-idr-bgp-ipsec-transport-mode-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822620352&sdata=9jeVZbLjEcC1gVDv5yxTAd9Ygi4ao9hi5GT2zeaAqco%3D&reserved=0>
Htmlized:       https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hujun-idr-bgp-ipsec-transport-mode&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488713364&amp;sdata=G3azT0TBfD9NmSvJ%2B%2BBaNCA70SFMM%2BEqrvX2IjTIef8%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hujun-idr-bgp-ipsec-transport-mode&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822620352&sdata=Ngxrm2VPjxe%2FuFVjOmmfyb%2BO1m6wfrAktnXqZE8vtp8%3D&reserved=0>


Abstract:
   This document defines a method of using BGP to advertise IPsec
   transport mode protected tunnel (like GRE tunnel with IPsec transport
   mode protection) configuration along with NLRI, based on
   [I-D.ietf-idr-tunnel-encaps] and [I-D.hujun-idr-bgp-ipsec].




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488713364&amp;sdata=5lz3DyKGqJb2asfcfarFXUtZptUy1XpsnAMsv6Rycic%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822630345&sdata=15nN9cU3KVLHUlU1OtYTBuiowhTuAIDyrohCrCQJgRs%3D&reserved=0>

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdb93469d32784754e52008d76b5a3300%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637095907488713364&amp;sdata=5lz3DyKGqJb2asfcfarFXUtZptUy1XpsnAMsv6Rycic%3D&amp;reserved=0<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C4bd1f219e66a4162ea8108d76bbc11c9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096327822630345&sdata=15nN9cU3KVLHUlU1OtYTBuiowhTuAIDyrohCrCQJgRs%3D&reserved=0>