Re: [Teas] FW: The word "transport"

[Gyan Mishra <[e-mail]>]

Agreed on most all your points in-line 😀

On Fri, May 1, 2020 at 6:40 AM Adrian Farrel <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> > I agree with the confusion of just the word “VPN” by itself
>
> > can mean many different things.
>
>
>
> Good, we start from a point of agreement 😊
>
>
>
> > VPN by itself usually means the “vpn technology” client to
>
> > net various flavors of a VPN tunnel such as IPSEC or SSL.
>
> >
>
> > Also could be net to net router to router IPSEC tunnel P2P
>
> > or P2MP MGRE DMVPN with the many flavors as well.
>
> >
>
> > Usually when VPN is mentioned in the context of “service”
>
> > it’s mentioned as Layer 3 vpn service overlay, which could
>
> > be over any underlay MPLS, SR flavors SRv6 or SR-MPLS or
>
> > MPLS-In-GRE or MPLS-in-UDP.
>
>
>
> I think this is where I disagree. It seems to me that you are coming at
> this from the perspective of an equipment engineer that makes boxes and
> protocols to enable network operators to deliver VPN services, or from the
> perspective of a network engineer tasked with building a network and
> delivering a service. And why shouldn’t you have that perspective? It’s
> where you’re standing, and perfectly fine.
>

But imagine that you are a customer (perhaps an enterprise) commissioning a
> VPN service. You are interested in the end points that are connected, and
> you care about the SLA/SLO. But when you say “VPN” you don’t mean SRv6 or
> MPLS-TE or whatever (unless you are one of those annoying customers that
> network operators really hate).
>
>
>
> And, obviously, the network operator sitting in the middle. For them a VPN
> is both the service sold and the technology used.
>
>   Good points as I took the term “VPN” placing in the technology context
and then also placing in the service context, but depending on the point of
view from where you are looking at it - as you state it could be seen as
both service and technology as well, adding to the confusion of use of the
word.

>
>
> So (clearly?), the use of the term “VPN” is context specific and somewhat
> fragile. I think “transport” falls into this class as well.
>
>  Agreed
>
> The solution is to either avoid using the terms, or to be really careful
> to provide sufficient and clear context.
>
> Completely agree
>
> > From the subject heading my take on the definition of “transport”
>
> > in the context of VPN+ or Enhanced VPN transport slicing is as follows.
>
> >
>
> > When I think of transport I think of the physical underlying resource
>
> > and hardware that makes up the physical infrastructure as a whole.
>
>
>
> Well, I understand that interpretation. It’s a common interpretation and
> the one typically seen in CCAMP.
>
>
>
> I don’t think that the VPN+ work uses that definition, and I think it is
> (attempts to be) clear on that point.
>
>  Agreed
>
> > When I think of the word “transports”  in the context of RSVP TE
>
> > I think of SRLG definition below of links that share common fate
>
> > - “ fate sharing” in the context of FRR n:1 facility protection or
>
> > node protection.
>
> >
>
> > The term “slice” I think of a slice of a pie where the sum of the
>
> > parts equal the whole.
>
> >
>
> > In the context of slicing I think 3D dimensionally as if cutting a pie
>
> > which could be a cross section of the networks if you look at in a
>
> > 3D logical construct.
>
> >
>
> > So you can think of the network as multi dimensional and take
>
> > multiple cross sections of the network from which you get the
>
> > layers construct that make up the physical topology.
>
>
>
> That may all be a bit complex, but I understand what you are saying.
>
>
>
> > So from a layer perspective just about every topology that
>
> > involves some kind of tunneling of traffic has the concept of
>
> > overlay and underlay.
>
>
>
> Like John says, this may be a more useful terminology.
>
>  Agreed
>
> > In the MPLS or SR world you can think of a 2 level deep label
>
> > stack where the topmost transport label is the “underlay” and
>
> > the service label bottom of stack being the overlay.
>
> >
>
> > So then going full circle looking at VPN+ or Enhanced VPN (EVPN)
>
> > framework sits in the overlay.
>
> >
>
> > I would not call it transport overlay as the underlay is the topmost
>
> > label underpinnings of resources isolation that you are trying to
>
> > pin the EVPN overlay service to.
>
> >
>
> > I think however since we are cutting the network so cross sectionally
>
> > and not horizontally it is more like a transport slice of the network
> pie.
>
>
>
> That’s probably a circular thing because that’s your definition of a
> transport slice.
>
>
>
> > I think if it was just a regular L3 VPN it would be an overlay would be
>
> > the right description but since we are carving our underlying resources
>
> > for this VPN service I agree it’s more like a transport slice.
>
>
>
> Well, playing with terminology a bit, yes, an L3VPN is an overlay when
> seen from outside. But when seen in the underlay, a L3VPN that is realised
> using TE tunnels that have resource reservations and follow specific paths
> (possibly avoiding other traffic, and possibly providing resilience) is
> using a “slice” of the underlay network.
>
> Understood.  Such as per VRF TE or SR-TE coloring or Flex Algo using a
> slice of the underlay with static ERO or cSPF dynamic with TE weights and
> included and excluded nodes in the path to meet underlay resource
> requirements for EVPN. We also today have DS TE CBTS and PBTS for flow
> based QOS SLA via RDM/MAM. Agreed.
>
> > There was a long thread on this similar topic with Xie on using
>
> > Isis MT for transport slicing.
>
> >
>
> > https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00
>
>
>
> Thanks for that pointer. I think this further serves to indicate that we
> need to clean up the terminology.
>
>
>
> > So now how would the isolation work with this EVPN or VPN+
>
> > transport slice that has its own dedication resources.
>
>
>
> Well, now we are firmly in solution space and not talking about
> terminology or architecture.
>
> Isolation is well described in draft-ietf-teas-enhanced-vpn and it is
> technology-dependent. For example, if the underlay is WDM, isolation might
> involve using different lambdas for different slices. OTOH, if the underlay
> is packet, isolation might require selection of non-overlapping paths
> (i.e., physical resources), of the reservation of different pools of
> buffers, or simply using different identifiers (such as labels).
>
>
>
> I do suggest reading the document.
>
>  Will do
>
> > Most vendors and modern routers have the Virtual router
>
> > concept vPE or vP, similar to NFV like VNF containers for
>
> > network functions.  So let’s say on a MPLS or SR core where
>
> > you are have a white box solution on merchant silicon and
>
> > have virtualization containers built.  So for each P and PE
>
> > router you have a dedicated container with dedicated
>
> > resources memory for the EVPN as it needs special
>
> > treatment for 5G RAN front and back hauls.  The remaining
>
> > L3 VPNs on the core boxes sit in a BAU container with
>
> > shared resources.  So there maybe cases where you might
>
> > have multiple EVPNs that need dedicated resources and for
>
> > those you have virtual router carved up enough resources to
>
> > meet the applications requirement.  So with the draft
>
> > mentioned each EVPN would sit isolated in its own Isis mt
>
> > instance providing complete control plane isolation on top of
>
> > the above router virtualization container based isolation.
>
>
>
> This is a fine way to deliver an enhanced VPN service or a network slice
> service. I would say it is only one way of doing it out of many ways.
>
> Agreed.  I know we are not delving I into solution space yet but sometimes
> imagining the solution and how it would work in theory in my mind sometimes
> helps me understand the benefits of the technology  *and it’s feasibility
> in the real world.*
>
Best,
>
> Adrian
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]