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

[Gyan Mishra <[e-mail]>]

Hi Med

After thinking about it further I agree with you  that hard and soft
isolation are distinctly different service characteristics and orthogonal
to each other.

I think of soft isolation as logical virtualization layer achieved by L3
VPN overlay for routing  traffic isolation.

I think of hard isolation as physical transport underlay layer isolation.

So both hard and soft isolation are distinctly separate service
characteristics.

However in the context of network slicing hard isolation is a
characteristic that can be applied to a VPN with inherently has soft
isolation.

Hard isolation is a super set of soft isolation as explained below building
on the degree of isolation.

However from a traffic steering perspective let’s say per VRF TE or SR path
isolation a service VPN color with its underpinning to a distinct LSP path
further isolates the logical soft isolation VPN overlay to now a distinct
physical hard isolation underlay path.  So our traditional VPN service
route that has achieved traffic isolation natively can be further isolated
with with its underpinnings to underlay transport layer NRP physical
isolation network slice per VRF TE or SR LSP instantiated.  So even though
soft and hard isolation are orthogonal to each other, a VPN with it’s
inherent soft isolation can be further isolated using hard isolation.

So in this particular case as I described a let’s say VPN A has its
inherent native soft isolation, but now the service was upgraded to VPN+
for hard isolation.

So now in this case the VPN A that has hard isolation would imply soft
isolation.

I think the concept of hard and soft isolation applies to a customer VPN
that could be further isolated using hard isolation techniques to achieve
hard isolation service characteristics.

Hard  and soft isolation could also apply to let’s a a global AWS  EC2
Instance for a particular quota service instance example of soft isolation,
but now to use a regional dedicated EC2 instance would be more costly which
would require many EC2 instances globally.  So in this example as well the
EC2 instance that has hard isolation does imply that it has soft isolation
as well.

Similarly from a IP VPN perspective you could have all your VPN customers
use the same transport path would be soft isolation as the routing traffic
is isolated for all customers into their own dedicated VPN.  Now we could
similar to the EC2 instance we can isolate each VPN onto its own dedicated
per VRF TE or SR path which would be hard isolation.

So the degree of isolation is not from spectrum necessarily from soft to
hard as soft is orthogonal and the starting point is the base NRP with all
VPNs sitting in a single default underlay.

So the degree of isolation refers to in my mind the degree of hard
isolation.  Has nothing to do with the soft isolation.

However VPN overlay traffic are the instances that benefit and would get
that further isolation “degree of isolation” hard isolation with an upgrade
to VPN+ service.

Degree or hard isolation would be based on the degree of underlay resources
link, node and queue resources sharing that exists and if more sharing the
less of a degree of hard isolation and less sharing then the greater the
hard isolation.

Thank you for the analysis and clarification as it really helped me
understand as well the difference between hard and soft isolation and that
they are different service characteristics.

Please comment on what I have stated and if it makes sense or not.

Many Thanks!

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*