Closed kireeti1 closed 3 years ago
We can add the new identities to the model. We could try to add all the types of tunnels available today to save time in the future
1. IP tunnels are used in DCs for L3VPNs (L3NM), and in aggregation networks for EVPNs (L2NM). Would be good to add: IP-in-IP, MPLS-in-UDP, VxLAN and Geneve to the list of identityrefs
Fixed now at both the common yang module and I-D.
For point 2, let's continue the discussion with the authors of https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-05 Adding a tunnel policy is a good option, so we need to figure out the best way to add it
For the service mapping issue, my preference is to go with mapping an L[23] VPN to a network slice for at least two reasons: a) a network slice is more general than either a TE tunnel or a virtual network; b) slices are the future, so they will have to be incorporated in any case. This could be as simple as a string with the slice name (and simple is good).
For the service mapping issue, my preference is to go with mapping an L[23] VPN to a network slice for at least two reasons: a) a network slice is more general than either a TE tunnel or a virtual network; b) slices are the future, so they will have to be incorporated in any case. This could be as simple as a string with the slice name (and simple is good).
When approaching this from another angle, the technical realization of a slice may rely upon a VPN, which itself relies upon some underlay transport capabilities. I wouldn't position a reference to a slice in the same level as the current "*-transport" node.
Adding a node to bind a VPN to a slice (or a set of slices ?) would make sense, though. And I agree, having a slice name (or id) would be sufficient.
Hi Med,
There are two concepts: an end-to-end slice (from 5G RAN, or including a VPN), and a transport slice. To achieve the former (for a VPN), one can use the service mapping to a transport slice.
Cheers, Kireeti. From: Med notifications@github.com Date: Monday, February 8, 2021 at 04:22 To: IETF-OPSAWG-WG/l3nm l3nm@noreply.github.com Cc: Kireeti Kompella kireeti@juniper.net, Author author@noreply.github.com Subject: Re: [IETF-OPSAWG-WG/l3nm] [proposed labels: L2NM, L3NM] Underlay Transport (7.3.3 in L3NM) (#208)
For the service mapping issue, my preference is to go with mapping an L[23] VPN to a network slice for at least two reasons: a) a network slice is more general than either a TE tunnel or a virtual network; b) slices are the future, so they will have to be incorporated in any case. This could be as simple as a string with the slice name (and simple is good).
When approaching this from another angle, the technical realization of a slice may rely upon a VPN, which itself relies upon some underlay transport capabilities. I wouldn't position a reference to a slice in the same level as the current "*-transport" node.
Adding a node to bind a VPN to a slice (or a set of slices ?) would make sense, though. And I agree, having a slice name (or id) would be sufficient.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/IETF-OPSAWG-WG/l3nm/issues/208#issuecomment-775108215, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANEREFYUXFJNUG7XRVYHBPLS57JQ7ANCNFSM4W6VIUTA.
Juniper Business Use Only
I would agree on including the reference to the slice using the agreed terminology in IETF and a reference to avoid misunderstanding.
Hence, if a "transport slice" is a valid option for creating the underlay... would it make sense to add it as another option in the uderlay container?
The extra item to add at the time being, until transport slices are further developed, could be to add a basic container with the id that can be augmented in the future.
Continue discussions in issue #212