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

[Gyan Mishra <[e-mail]>]

All

In that example of 3 link coloring of the transport Gold, Bronze, Silver
using Flex Algo each color could limit the number of customer mapped to the
slice coloring providing degrees of isolation.

Gold - maximum 50 customers
Silver - maximum 100 customers
Bronze - maximum 200 customers

Kind Regards

Gyan

On Wed, Jan 11, 2023 at 8:05 PM Gyan Mishra <[e-mail]> wrote:

>
> 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*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*