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

[Joel Halpern <[e-mail]>]

Gyan, the number of customers is almost completely unrelated to any 
meaningful service parameter.  And limiting reserved bandwidth is what 
existing traffic engineering does, without any "isolation".

More importantly as far as I am concerned, there seems no way for me to 
tell if any of the meanings you have suggested are what the draft means 
by "hard isolation" or the spectrum from "soft" to "hard" isolation.  I 
suspect that Med is correct and we are mixing concepts that should be 
separated.

Yours,

Joel

On 1/11/2023 9:53 PM, Gyan Mishra wrote:
>
> 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]//
>     /
>
>     /M 301 502-1347
>
>     /
>
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email [e-mail]//
> /
>
> /M 301 502-1347
>
> /
>
>