To make it easier for people to provide feedback, we added a Gap Summary
section to draft-ietf-rtgwg-net2cloud-gap-analysis
Here is the summary of the technical gaps discussed in this document:
- For Accessing Cloud Resources
a) When a remote vCPE can be reached by multiple PEs of one
provider VPN network, it is not straightforward to designate which egress PE to
the remote vCPE based on applications
b) Need automated and reliable tools to map the user-friendly
(natural language) access rules into machine readable policies and to provide
interfaces for enterprises to self-manage policy enforcement points for their
own workloads.
c) NAT Traversal. An enterprise's network controller needs to be
informed of the NAT properties for its workloads in Cloud DCs. If the workloads
are attached to the enterprise's own vCPEs instantiated in the Cloud DCs, the
task can be achieved.
d) The multicast traffic to/from remote vCPE needs a feature like
Appointed Forwarder specified by TRILL to prevent multicast data frames from
looping around.
e) BGP between PEs and remote CPEs via untrusted networks.
f) Traffic Path Management
- Overlay Edge Node's WAN Port Management: BGP UPDATE propagate client's routes
information, but don't distinguish network facing ports.
- Aggregating VPN paths and Internet paths
a) Control Plane for Overlay over Heterogeneous Networks is not
clear.
b) BGP UPDATE Messages missing properties:
- Lacking SD-WAN Segments Identifier
- Missing attributes in Tunnel-Encap
c) SECURE-L3VPN/EVPN is not enough
d) Missing clear methods in preventing attacks from
Internet-facing ports
Looking forward to any feedback or suggestions.
Thank you very much
Linda Dunbar
-----Original Message-----
From: Linda Dunbar
Sent: Wednesday, March 18, 2020 9:21 PM
To: rtgwg-chairs <[email protected]>; [email protected]
Subject: Request for WGLC for draft-ietf-rtgwg-net2cloud-problem-statement-09 &
draft-ietf-rtgwg-net2cloud-gap-analysis-05
Chris and Jeff,
We have made significant changes to address the comment and suggestions from
IETF106, email discussions and other IETF WGs.
We have removed all reference to SD-WAN from those two drafts, making the
drafts primarily focusing on the problems and gaps of networks to connect
enterprise premises with hybrid cloud data centers.
We believe the following documents are ready for WGLC. Can you please start the
WGLC for the following drafts?
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
thank you very much.
Linda Dunbar
-----Original Message-----
From: Linda Dunbar
Sent: Wednesday, March 18, 2020 5:54 PM
To: 'Hollenbeck, Scott'
<[email protected]<mailto:[email protected]>>
Cc: '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]'
<[email protected]<mailto:[email protected]>>
Subject: RE: DNS for Cloud Resources in
draft-ietf-rtgwg-net2cloud-problem-statement-08
Scott,
Here is the revised version with your suggested changes incorporated:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
Thank you very much for the review and suggestion.
Linda Dunbar
-----Original Message-----
From: Linda Dunbar
Sent: Monday, March 16, 2020 12:01 PM
To: Hollenbeck, Scott
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: DNS for Cloud Resources in
draft-ietf-rtgwg-net2cloud-problem-statement-08
Scott,
Thank you very much for the suggestion. Have changed the text per your
suggestion. Will upload the new version when the IETF submission opens up next
Monday.
Linda
-----Original Message-----
From: Hollenbeck, Scott
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, March 11, 2020 1:19 PM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: DNS for Cloud Resources in
draft-ietf-rtgwg-net2cloud-problem-statement-08
(Sorry, this is a late response to a review request original sent to the dnsop
list on 11 February)
Section 3.4 (DNS for Cloud Resources) includes these sentences:
"Globally unique names do prevent any possibility of collision at the present
or in the future and they make DNSSEC trust manageable. It's not as if there is
or even could be some sort of shortage in available names that can be used,
especially when subdomains and the ability to delegate administrative
boundaries are considered."
Could we make the last sentence stronger, perhaps with a statement like this
from the US CERT WPAD Name Collision Vulnerability alert dated May 23, 2016?
"Globally unique names do prevent any possibility of collision at the present
or in the future and they make DNSSEC trust manageable. Consider using a
registered and fully qualified domain name (FQDN) from global DNS as the root
for enterprise and other internal namespaces."
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.us-cert.gov%2Fncas%2Falerts%2FTA16-144A&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cc4a7c2f2e85741d5b8a308d7c5e8eef1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637195476559397274&sdata=vBnDcnkZ8Zsk7MT610GQOsRQVt7G%2BLscbvwiDWXX%2Fvc%3D&reserved=0
The alert actually says "other internal namespace", but I think that's a typo.
Scott
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
