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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Med,

Thanks for providing your view on this. 

I fully agree with you that isolation can be classified into different types. As described in the draft, soft isolation refers to the requirements on "traffic and routing isolation" (thanks for pointing to RFC 4176) , and hard isolation is used to describe the requirement on "interference isolation". The text in the draft could be made clearer on these two types of isolation, and it would be great if you could help to propose some text. 

I also agree that each type of isolation may have different levels, and operator could map them to different realization mechanisms in their networks (depends on the toolset they have). I see it is useful for Section 3.2 to briefly mention this without talking too much about the implementation details. What do you think?

Best regards,
Jie

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, January 11, 2023 4:13 PM
> To: Joel Halpern <[e-mail]>; [e-mail]; Dongjie
> (Jimmy) <[e-mail]>
> Cc: 'TEAS WG' <[e-mail]>; JACQUENET Christian INNOV/NET
> <[e-mail]>
> Subject: RE: [Teas] WG Last Call: draft-ietf-teas-enhanced-vpn-11 - isolation
> 
> 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.