[ first, apologies for forging a message from joe to the list ] back in october 2016, i said
> 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. 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
