Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

From: Joe Clarke <[email-masked]>
Date: Tue, 06 Nov 2018 01:43:47 -0000

> Hi Randy, today, at IETF96 in Berlin, we discussed this document in
> the OPSAWG meeting. 
> We would be interested to hear your opinion (from an operator point of
> view) on this document.  It is a short document. Hearing if you think
> this makes sense or not would be great.
> You can send you comments to me directly or (preferably) to the opsawg
> mailing list at [email-masked]

at this level of abstraction, anything can be made to look as if it
would work and be wonderful.  it essentially says that a multi-as vpn is
composed by linking multiple single-as vpn systems.  this is not a deep
insight, and it provides no clues on how to do it.

of the 392 devils to be found in the details, inter-provider
authentication and identification of end-points, billing, ...  the list
goes on and one.

then there are issues such as describing and provisioning the contracted
(with the end customer) privacy constraints across multiple provider
technologies.

fwiw, our customers do use multi-provider vpns; they use ipsec.  we
provide ipsec capable cpe and various management/orchestration systems.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Nov 2018 08:52:22 +0700

[ first, apologies for forging a message from joe to the list ]

back in october 2016, i said

> provide ipsec capable cpe and various management/orchestration systems.

the draft in $subject is an even higher level description of the same
unsolved problems.  while i do admire and encouragethe use of more
formal abstractions, it would also be good if the real underlying issues
were addressed.  perhaps, likely due to undercaffeination, i missed
seeing the semantics being clarified.  if so, my apologies.

randy

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 6 Nov 2018 08:20:58 +0000

Hi,
The draft-deng-opsawg-composed-vpn-sm-requirement had a more general approach. In this document we are looking at a single service provider that has more than one domain and has the interconnects. The data model allows that service provider to specify the composed VPN and provide the orchestrators with the information to configure the segments VPN , assuming that the connectivity between the domains is given
Roni 

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Tuesday, November 06, 2018 8:52 AM
To: opsawg
Subject: Re: [OPSAWG] draft-evenwu-opsawg-yang-composed-vpn

> would work and be wonderful.  it essentially says that a multi-as vpn 
> is composed by linking multiple single-as vpn systems.  this is not a 
> deep insight, and it provides no clues on how to do it.
> 
> authentication and identification of end-points, billing, ...  the 
> list goes on and one.
> 
> then there are issues such as describing and provisioning the 
> contracted (with the end customer) privacy constraints across multiple 
> provider technologies.
> 

the draft in $subject is an even higher level description of the same unsolved problems.  while i do admire and encouragethe use of more formal abstractions, it would also be good if the real underlying issues were addressed.  perhaps, likely due to undercaffeination, i missed seeing the semantics being clarified.  if so, my apologies.

randy

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg