Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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.dong@huawei.com> wrote:

> Hi Robert,
>
>
>
> Thanks for your email. Please see some replies inline with [Jie]:
>
>
>
> *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, January 27, 2021 8:03 PM
> *To:* James Guichard <james.n.guichard@futurewei.com>
> *Cc:* spring@ietf.org; spring-chairs@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.guichard@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
>
>