Jie, > [Jie] Agree that with MPLS-TE the reservation could just happen in the control plane
This is not "could" ... this is real - they *are* happening all in control plane only. The only data plane reservations were done with RSVP Int-Serv (for those who still even remember this) and you see how far it went. For IP networks based on statistical multiplexing hard allocation of any data plane resources == waisted resources. Many thx, R. On Wed, Jan 27, 2021 at 4:39 PM Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > Hi Robert, > > > > Thanks for your email. Please see some replies inline with [Jie]: > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Wednesday, January 27, 2021 8:03 PM > *To:* James Guichard <james.n.guich...@futurewei.com> > *Cc:* spring@ietf.org; spring-cha...@ietf.org > *Subject:* Re: [spring] WG Adoption Call for > draft-dong-spring-sr-for-enhanced-vpn > > > > All, > > > > Before I make a decision on expressing my support or indicate no support I > would like to better understand what resource reservation is being > discussed here. > > > > [Jie] The resource reservation here refers to the data plane resources > reserved for different virtual transport networks. > > > > draft-ietf-spring-resource-aware-segments-01 also talks about > "reservations" yet lacks clarity what those reservations will actually be. > It provides analogy to MPLS-TE, but at least those who build MPLS-TE > products are aware MPLS-TE or even MPLS GB-TE does not provide any data > plane reservations. All both do is to provide control plane resource > bookings. > > > > [Jie] Agree that with MPLS-TE the reservation could just happen in the > control plane and does not have to be in the data plane. > draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency > of the controller based resource management with existing SR in some > scenarios, thus both the resource-aware-segments draft and this draft are > talking about data plane resource reservation. > > > > So fundamentally does draft-ietf-spring-resource-aware-segments-01 and > this draft in question also are trying to now map SIDs to control plane > resource bookings ? Note fundamentally in all above cases it only works > when all traffic in yr network is actually using such reservations as > otherwise unaccounted traffic will destroy the game completely for those > who think we see green light we are good to go. That is also why for real > TE it is/was critical in MPLS-TE to provide such engineering for all of > your ingress-egress macro flows. > > > > [Jie] As explained above, the idea is to associate different SIDs with > different sets of data plane resources reserved in the network, so that > traffic encapsulated with different SIDs will be steered into different set > of data plane resources. This way the unaccounted traffic in your example > will only be allowed to occupy the set of resources which are associated > with the SIDs carried in the packet. Thus the mechanism could work without > per-flow engineering. > > > > Even then if you start to run other traffic on the same links ... say > multicast or control plane storms of any sort - again all of your assumed > reservations are immediately becoming unnecessary complexity with zero > benefits. > > > > [Jie] Similarly, based on the above mechanism, the impact of multicast or > control plane storms can also be limited to a subset of data plane > resources. This is the benefit of the data plane resource reservation. > > > > So with that let's make sure we understand what is being proposed here. > > > > Btw if someone has a pointer to discussion about > spring-resource-aware-segments it would be great too. My few years of email > history does not return much. Maybe the draft got renamed during publishing > as SPRING WG item. > > > > [Jie] The history is, draft-ietf-spring-resource-aware-segments was part > of draft-dong-spring-sr-for-enhanced-vpn. After the first the adoption poll > on this document last year, based on the received comments and the chairs’ > suggestion, it was split out as a general enhancement to SR, and the rest > part of draft-dong-spring-sr-for-enhanced-vpn continues as an application > of the resource-aware segments. > > > > Hope the above helps to provide some background information. > > > > Best regards, > > Jie > > > > Thx, > R. > > > > > > On Wed, Jan 27, 2021 at 12:46 PM James Guichard < > james.n.guich...@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 2 week WG adoption call for > https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ > ending February 10th 2021. > > > > After review of the document please indicate support (or not) for WG > adoption to the mailing list and if you are willing to work on the > document, please state this explicitly. This gives the chairs an indication > of the energy level of people in the working group willing to work on this > document. Please also provide comments/reasons for your support (or lack > thereof) as this is a stronger way to indicate your (non) support as this > is not a vote. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
