search

IETF-OPSAWG-WG / lxnm

L3 VPN Yang Model
8 stars 11 forks source link

[proposed labels: L2NM, L3NM] Underlay Transport (7.3.3 in L3NM) #208

Closed kireeti1 closed 3 years ago

kireeti1 commented 3 years ago
  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
  2. tunnel characteristics would be a useful addition: a. "color" (generic, to choose between multiple RSVP-TE or SR tunnels between a pair of nodes); b. desired protection (none, edge-diverse, node-diverse, live-live, ...)
oscargdd commented 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

boucadair commented 3 years ago 
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.

Diff editor copy vs published version

oscargdd commented 3 years ago

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

kireeti1 commented 3 years ago

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).

boucadair commented 3 years ago

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.

kireeti1 commented 3 years ago

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

oscargdd commented 3 years ago

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.

oscargdd commented 3 years ago

Continue discussions in issue #212