Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Tony & John,

To your scale observations.

Assume we compare actions to 26 letters in the English alphabet and
network to a book.

Does this mean that each book must at least contain fact(26) of words ?

That would be 403,291,461,126,605,635,584,000,000 of them :)

I am focusing on picking words which are operationally useful and pointing
to those words with RFV as pragmatic and operationally valid approach.

Cheers,
Robert.


On Thu, 28 Apr 2022 at 01:26, Tony Li <[e-mail]> wrote:

>
> Hi Robert,
>
> I am looking at this problem from a practical point of view and what is
> realistically needed.
>
> If you support today 100 different ACL actions today do you size your
> boxes to support all possible combinations of those actions or do you
> rather see that in practical deployments users will be selecting few of
> those as needed to realize their objective ?
>
>
>
> Well, as you know, a customer will actually ask us to support what we
> claim to support. :)
>
> If we claim to support 100 ACLs, then we darn well better support 100
> ACLs.  So there will be an array some place of 100 ACLs.
>
> Each ACL will be arbitrarily long and of course consumes memory. If the
> total is too large, it will be a problem.
>
>
> And do not get me wrong, all 100 are nice to have as each user may have a
> different need, but no one uses all of them in any (even unordered)
> fashion.
>
> And to your example if some actions require unique 32 bit parameters SRv6
> may be a much better overall option. I just don't think we have such real
> needs today for MPLS networks so trying hard to
> take a very deployment driven solution with minimal change to data plane.
> And to keep MPLS packet size as small as possible.
>
>
>
> Or, maybe carrying parameters in ISD isn’t such a bad thing after all.
>
>
> Besides in my case if I use SR-MPLS as replacement for LDP with single top
> label I can easily still provide for the same RFV different chains at P
> routers vs ABRs vs area 0 or area 1 etc ... I am not sure how would you do
> that with MNA architecture without artificially inserting bunch of Segment
> Endpoints on what are SR unaware nodes. That seems to me like an
> architecture challenge for MNA - even for single flow. So this looks like a
> functional issue.
>
>
>
> I don’t claim ANY SR expertise, especially with multiple areas involved.
>
> If RSVP were involved, then I would think it’s straightforward: a top
> level LSP label and then MNA underneath it.
>
> Similarly, if we had domain wide labels, you stick MNA underneath that and
> you’re done.
>
> So it seems like this isn’t about MNA so much as the forwarding mechanism
> and the inherent scalability issues of SR.
>
> T
>
>
>
>