Re: [Teas] WG Last Call: draft-ietf-teas-enhanced-vpn-11 - isolation

[Gyan Mishra <[e-mail]>]

All

Another way to think of hard and soft isolation, is hard isolation is
dedicated transport where soft isolation is shared transport.

So the sharing can be done using multi tenancy like DC NVO encapsulations
of IP VPN, client-net or net-net VPN access.  When you think of soft
isolation there is an overlay and underlay and there is a many to 1 mapping
between the overlay and underlay which VXAN, L3 VPN, VLAN are excellent
examples of soft isolation.

Hard isolation is isolating traffic to a dedicated path or transport “path
isolation” using SR or RSVP-TE dedicated LSP per VRF TE isolated path.  So
here we have the overlay to underlay is a 1 to 1 mapping single customer
using the transport so here it’s a dedicated transport to that single
customer.

Think of soft slicing or isolation  as the overlay carving and slicing and
think of hard slicing or hard isolation is carving up the underlay
transport.

Soft is logical or virtual and hard is physical.

So when you think of network slicing or let’s say flex algo link coloring
which is a good example of how to instantiate the IETF network slice you
can have have all your customers VPNs many to 1 map to a single transport
which is soft isolation or you could take your top tier customers and give
each top tier customer their own dedicated transport so a 1-1 mapping VPN
overlay to underlay.

That is quite expensive and makes hard isolation impractical.

So this is where “degree of isolation” comes into play and flex algo link
coloring is a great example of degree of isolation.

So let’s say now you only want gold bronze and silver class VPNs to share
this top tier VPN+ IETF network slice you would have 3 colors / Algo’s on
these continuous links overlaid onto the transport fabric versus carrying
1000s of VPNs your traditional L3 VPN on shared evenly transport 1 to many
mapping.  The Gold, Bronz, Silver classes would map to a minimal number of
VPNs for this top tier service offering.   In this SP network example all
other BAU VPNs would use the traditional shared soft isolation transport
which could be a different shared flex algo.

When you think of network slicing what are you doing ?

You are creating a degree of sharability of the VPN overlay to underlay
underpinning from many to 1 to fewer to 1 so lesser sharing resulting in
improved SLO SLE markers and value add for SP.

That degree of sharability is the degree of isolation.

The degree of isolation goes against binary on or isolation, 100% isolation
or no isolation.

Binary view of isolation is impractical and of course does not scale.  If
you use binary terms you are in fact not doing network slicing.

So any SP wanting to slice a pie and create larger pieces and not have
everyone share the pie - that is network slicing and that concept is degree
of isolation.

So this gives a pictorial real world example of degree of network slicing.

Hopefully that helps explain 3.2 and it’s importance.



Kind Regards

Gyan
On Wed, Jan 11, 2023 at 3:13 AM <[e-mail]> wrote:

> Hi Joel, all,
>
> I suspect that the root of the disconnect here is that we are using the
> same term (isolation) to denote to distinct aspects of service provisioning
> (that we used to refer to with distinct terms, BTW).
>
> What is called "soft isolation" is what we used to call "traffic
> isolation" or "traffic and routing isolation" (see, e.g., RFC4176).
> Stronger forms can be requested as part of this isolation (L2/L3 encryption
> at the VPN network access, dedicated transport tunnels between PEs, etc.).
> Some sensitive sectors may request audits/certifications to attest that a
> network is reliably meeting this.
>
> What is called "hard isolation" in the draft is no more than protecting
> against service interference. A service will be perceived with the
> requested objectives independent of whether other services are soliciting
> the same shared resources, are encountering failures, are aggressively
> seeking to grab more resources, etc. The QoS/TE/Policy toolkit can be used
> here. A (very simple) implementation example to meet this objective for
> services that require global connectivity via proxies is to configure
> quotas per service on the proxy. A more costly approach would be to
> instantiate a dedicated proxy instance for this service. Modelling "hard
> isolation" as a Boolean wouldn't be sufficient here, but this is out of
> scope of this draft.
>
> The current text in the draft suggests that requesting "hard isolation"
> would imply that "soft isolation" is also ensured...which is not true.
>
> I tend to suggest abandoning the soft/hard thing but refer to these as two
> distinct service characteristics.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Teas <[e-mail]> De la part de Joel Halpern
> > Envoyé : mardi 10 janvier 2023 20:26
> > À : [e-mail]; 'Dongjie (Jimmy)' <[e-mail]>
> > Cc : 'TEAS WG' <[e-mail]>
> > Objet : Re: [Teas] WG Last Call: draft-ietf-teas-enhanced-vpn-11 -
> > isolation
> >
> > While I tend to wonder a bit some days, I do mostly see the value
> > in SLEs.  (We can discuss examples over bevarage at some meeting
> > to see why some days I am skeptical, but I am  not objecting to
> > the general premise of SLEs,.)
> >
> > If the Isolation were strictly about address isolation, I would
> > probably not object.  (There is "don't delvier to others", there
> > is the VPN version, which is somewhat stronger.)
> >
> > But what the text says is that there is something called hard
> > isolation.  And based on the YANG I have seen from the same
> > participants, there is a knob that one can turn.  But, other than
> > meeting SLOs, I hav eno idea what a customer, implementor, or
> > operator would do differently if that knob were set at various
> > points.  As such, I find the description confusing and
> > unimplementable as described.  One can claim this is only a
> > framework, but I do not even know how I would evaluate a
> > realization to decide if it were offering soft, medium, hard, or
> > extra-firm isolation.
> >
> > Yours,
> >
> > Joel
> >
> > PS: I actually think the example of multicast may be a bad
> > example, as I am not at all sure there is a commitment not to
> > deliver the multicast to other places.  VPNs do seem to have a
> > "only within the VPN" scoping that is closer to what you describe.
> >
> > On 1/10/2023 2:10 PM, Adrian Farrel wrote:
> > > May I offer an interjection as someone who provided some of the
> > wording for rehashing the VPN+ isolation text a while back?
> > >
> > > Let us consider a multicast service offered to a customer. In
> > this service, traffic is delivered from site A to sites B, C and D
> > (all belonging to the same customer). It is clearly up to the
> > operator how they choose to realise this multicast delivery within
> > their network.
> > >
> > > However, there is an obvious requirement from the customer that
> > the traffic is not also delivered to site E belonging to another
> > customer. Such requirements are so fundamental that we tend to not
> > talk about them, but you can be sure that they are there in the
> > small print of the customer agreement.
> > >
> > > This "non-delivery to other customers" requirement is a form of
> > isolation. But, most importantly, it is an SLE. The customer
> > cannot measure this. The customer has no good way of knowing
> > whether an extra copy of the traffic is being delivered to
> > somewhere it shouldn't go.
> > >
> > > There is, therefore, a contract that makes a promise, and a
> > customer who may, very probably, never know if the contract is
> > broken. If they do find out, by some means, they will get cross.
> > But until then, this is a matter of trust between the customer and
> > provider.
> > >
> > > (There is also, probably, a converse of this requirement where a
> > > customer does not want to be flooded with traffic that does not
> > belong
> > > to their service. That, too, is a form of isolation.)
> > >
> > > My argument, therefore, is that these SLEs are very real, and
> > express the expectations that the customer has, and the behaviors
> > that the operator will want to implement.
> > >
> > > Of course, for many of the aspects of isolation, it is enough
> > for the SLOs to be set carefully, and for the service to conform.
> > Who cares whether service B causes a degradation in the latency
> > being delivered to service A, if service A is still within the
> > bounds of the latency SLO set in the SLA? This point is, I
> > believe, made abundantly clear in the second paragraph of Section
> > 3.2.
> > >
> > > Furthermore, different isolation tools may only be available in
> > certain network technologies. For example, the concept of
> > dedicating switching resources to a particular service makes more
> > sense in a physically switched network (TDM, WDM, ...) than it
> > does in a fully multiplexed packet network. Nevertheless, there
> > are networks and their customers where whole ports/links are
> > dedicated for the use of traffic flows from one customer (with the
> > extreme case being that the operator builds a totally dedicated
> > network for the customer). This is done because the customer is
> > willing to pay. Sometimes they are paying for a set of extremely
> > stringent SLOs. Sometimes they are paying for their service levels
> > to be "no worse than" those of their competitors.
> > >
> > > So I am trying to understand whether the push-back on the
> > isolation text is philosophical ("I don't see the need to talk
> > about isolation"), technical ("I don't see how this would map to
> > implementation/deployment in the operator's network"), or textual
> > ("I read the text, but it doesn't convey any meaning to me"). I
> > would answer:
> > > 1. Some people see the need, so that's where we are.
> > > 2. I think that this document is supposed to provide an overview
> > of relevant technologies, so it could include additional guidance
> > if what is there is not enough.
> > > 3. This is hard to resolve, but is best done by asking questions
> > about isolation, and then having the answers incorporated into the
> > text.
> > >
> > > I hope this helps reach a solution rather than just muddying the
> > waters.
> > >
> > > Best,
> > > Adrian
> > >
> > > -----Original Message-----
> > > From: Teas <[e-mail]> On Behalf Of Joel Halpern
> > > Sent: 10 January 2023 14:50
> > > To: Dongjie (Jimmy) <[e-mail]>; TEAS WG
> > <[e-mail]>
> > > Subject: Re: [Teas] WG Last Call: draft-ietf-teas-enhanced-vpn-
> > 11 -
> > > isolation
> > >
> > > I understand that isolation as a concept is in the Framework
> > draft and
> > > in the 3GPP documents.  The 3GPP documents as I understand it
> > are very
> > > general about what it means (although I have seen come clear
> > > interpretations as they apply to cellular radio interfaces).
> > Our
> > > slicing framework is of course not specific as to the meaning.
> > While
> > > I was tempted to ask to remove it there, I concluded that as an
> > > example of something that could be an SLE, it is workable.
> > >
> > > However, this document is about a more specific realization.  It
> > > refers to degrees of isolation.  I have no idea what I as an
> > > implementor or operator would do differently based on the
> > degrees of
> > > isolation.  So I have a real problem with understanding the
> > text.
> > > (Note, this also applies to the YANG model, where we have a
> > field
> > > defined without a clear
> > > meaning.)
> > >
> > > I can not even tell what purpose the section in the VPN+
> > framework
> > > serves.  As such, I can not begin to suggest clarifications.
> > >
> > > Yours,
> > >
> > > Joel
> > >
> > > On 1/10/2023 4:01 AM, Dongjie (Jimmy) wrote:
> > >> Hi Joel,
> > >>
> > >> It seems my point was not interpreted clearly. So let me try
> > again:
> > >>
> > >> 1. Isolation is formally defined as one SLE in the IETF network
> > slice framework, and also one of the service requirements
> > specified in 3GPP TS 28.530. I think we don't need to spend
> > further time on whether isolation should be mentioned or not.
> > >>
> > >> 2. Isolation can be described as part of the service
> > requirements of the VPN+ customer. The requirements on the degrees
> > of isolation could be mapped to appropriate mechanisms in the
> > network for VPN+ realization. This draft also gives examples of
> > the resource partitioning mechanisms used to achieve isolation.
> > >>
> > >> 3. This framework document describes the architecture and the
> > candidate technologies for realizing VPN+. Operators can define
> > the specific types of services (including the degrees of
> > isolation) they would like to provide, and the corresponding
> > mechanisms they would use in the network for service delivery.
> > >>
> > >> In summary, the isolation text in this document aligns with the
> > definition and description in other documents, and provides useful
> > information to this framework document. If you still have specific
> > concerns, proposing text would be welcome.
> > >>
> > >> Best regards,
> > >> Jie
> > >>
> > >>> -----Original Message-----
> > >>> From: Joel Halpern [mailto:[e-mail]]
> > >>> Sent: Tuesday, January 10, 2023 12:19 AM
> > >>> To: Dongjie (Jimmy) <[e-mail]>; TEAS WG
> > <[e-mail]>
> > >>> Subject: Re: [Teas] WG Last Call: draft-ietf-teas-enhanced-
> > vpn-11 -
> > >>> isolation
> > >>>
> > >>> Not sure I understand all of your reply.  I think what you are
> > >>> saying implies that with regard to isolation the framework is
> > >>> significatnly incomplete and needs more work before we can
> > send it
> > >>> to the IETF. Currently, as far as I can tell the document
> > implies
> > >>> that technologies realizing vpn+ need to meet isolation goals,
> > but
> > >>> gives no hint as to what thosse goals are or how they could be
> > met.
> > >>> I have no idea how I would evaluate a realization as to
> > whether it
> > >>> was doing enough, too much, or not enough, to meet the
> > framework requirements.
> > >>>
> > >>> Yours,
> > >>>
> > >>> Joel
> > >>>
> > >>> On 1/9/2023 11:03 AM, Dongjie (Jimmy) wrote:
> > >>>> Hi Joel,
> > >>>>
> > >>>> Thanks for your review and comments.
> > >>>>
> > >>>> Since isolation is considered as one of the SLEs in the IETF
> > >>>> network slice
> > >>> framework, and has been mentioned as one of the network slice
> > >>> service requirements in the wireless community, it is
> > considered
> > >>> useful to also have it described in this document. The text
> > could
> > >>> always be polished based on discussion and suggestion.
> > >>>> As mentioned in my reply to Greg, a customer's requirement on
> > >>>> isolation is
> > >>> not the same as the requirement on a specific set of SLOs. In
> > some
> > >>> cases, meeting a set of SLOs could be considered as one way to
> > >>> indicate that the isolation requirement is also met, it is not
> > the
> > >>> only way. And in some cases not meeting the SLOs does not mean
> > the isolation requirement is not met.
> > >>> The SLO violation could be due to some other reasons. Thus it
> > is
> > >>> better to have both the isolation and the set of SLOs
> > described as parts of the SLA.
> > >>>> As described in the draft, there is distinction between how
> > >>>> isolation is
> > >>> requested by customer, and how it is delivered by the service
> > provider.
> > >>> Customers from different industries could have different
> > >>> requirements on isolation, accordingly operator may design
> > their
> > >>> services to match those requirements. Then in the underlay
> > network,
> > >>> specific resource partitioning and reservation mechanisms
> > could be
> > >>> chosen to realize the VPN+ service. As a framework document,
> > it
> > >>> would be helpful to cover different customer's requirements,
> > different service design and realization of the operator.
> > >>>> Best regards,
> > >>>> Jie
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Teas <[e-mail]> On Behalf Of Joel Halpern
> > >>>>> Sent: Saturday, January 7, 2023 12:38 AM
> > >>>>> To: TEAS WG <[e-mail]>
> > >>>>> Subject: Re: [Teas] WG Last Call: draft-ietf-teas-enhanced-
> > vpn-11
> > >>>>> - isolation
> > >>>>>
> > >>>>> I have reread section 3.2 multiple times.  And I am left
> > somewhat
> > >>>>> confused.  I presume I am missing something.  Axs far as I
> > can
> > >>>>> tell, the section is either over-speciying something, or
> > under-specifying it.
> > >>>>>
> > >>>>> On the one hand, the document seems to be quite useful
> > without the
> > >>>>> section.  And the section itself says that the isolation can
> > be
> > >>>>> delivered by meeting the SLOs.  So why do we need a section
> > about
> > >>> isolation?
> > >>>>> On the other hand, the section implies that one could want
> > to do
> > >>>>> something more than just meet the SLOs, and that somehow the
> > >>> customer
> > >>>>> could ask for that.  Except that at that point I have no
> > >>>>> information from the draft as to what would or would not
> > >>>>> constitute such stronger isolation, since it would not be
> > subject
> > >>>>> to observations (not be an SLO).  So if there really is
> > something
> > >>>>> more that enhanced VPN wants to deliver in this regard, I
> > think it
> > >>>>> needs to be described, so we can decide
> > >>> if we agree that it is part of the framework?
> > >>>>> Yours,
> > >>>>>
> > >>>>> Joel
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Teas mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/teas
> > > _______________________________________________
> > > Teas mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*