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

[[e-mail]]

Hi Jie,

> would be great if you could help to propose some text

Sure. Will send you a text proposal offlist. 

Cheers,
Med

> -----Message d'origine-----
> De : Dongjie (Jimmy) <[e-mail]>
> Envoyé : vendredi 13 janvier 2023 07:56
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> Joel Halpern <[e-mail]>; [e-mail]
> Cc : 'TEAS WG' <[e-mail]>; JACQUENET Christian INNOV/NET
> <[e-mail]>
> Objet : RE: [Teas] WG Last Call: draft-ietf-teas-enhanced-vpn-11 -
> isolation
> 
> 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.


_________________________________________________________________________________________________________________________

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.