[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] Reference Augmented Forwarding - MPLS RAF
From: Robert Raszuk <rraszuk () gmail ! com>
Date: 2022-04-29 19:20:57
Message-ID: CA+b+ERmaVNvZRZLPukAQ1n=c6SvoVaMCYDq2XTyiLGmpWnz6Xg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Tony,
Happy to see that we agree (I risk to state) on everything below.
We've been talking about carrying per-action capabilities for exactly this
> purpose. If a flow aggregate needs action MNA_3, then the PCE computes a
> path along nodes that are only MNA_3 capable. This should have zero impact
> on other flow aggregates.
>
> And remember RAF specifically targets spots not the entire network to
> execute additional network functions.
>
> I got that the first time, no need to keep repeating yourself.
>
Oh I restated this not to sound like a broken vinyl record, but to
underscore the issue I see combining the ideas.
So if I need to traverse subset of topology which support given service and
I want this service to be executed *on each node* on my flow aggregates why
not to simply use Prefix-SID and flex-algo ? Why do we need MNA for it ?
What is value add here ? Is there some delta or better advantage I am not
seeing ?
Why don't you define your actions as part of given's flex-algo
algorithm and do not use ISD nor PSD - just forward based on given
flex-algo Prefix-SID ?
Is the concern in one octet limit of the number of algorithms ? If so that
is why I wanted to better understand what physical forwarding differences
one expects to see across such topologies.
Well in the vast majority of my deployment RAF tuple should not be modified
> anywhere in the network.
>
> It must be inserted at some point. And if MNA is used, then it must be
> inserted as well.
>
Ok I was not considering "insertion" as "modification".
Hmmm didn't you say the other day that each LSR needs to parse the entire
> stack anyway in search for SPLs ? Remember my comment during the last
> meeting .. today label stack has no offset so you do not know what it
> contains till you parse it. Heavy !
>
> This is true. Already happening for EL.
>
I have a bit of a different opinion here .. especially for the cases where
nodes take the entire label stack as input for hashing without even
recognizing that part of that is EL.
The future of ANY feature is more about operator demand (i.e., $$$) than
> anything else.
>
100%.
Kind regards.
Robert
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Hi Tony,</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Happy to see that we \
agree (I risk to state) on everything below. </div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"><div>We've been talking about carrying per-action \
capabilities for exactly this purpose. If a flow aggregate needs action MNA_3, then \
the PCE computes a path along nodes that are only MNA_3 capable. This should have \
zero impact on other flow aggregates.<br></div><blockquote type="cite"><div><div \
dir="ltr"><div class="gmail_quote"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:small">And remember RAF \
specifically targets spots not the entire network to execute additional network \
functions. </div></div></div></div></div></blockquote><div>I got that the first \
time, no need to keep repeating \
yourself.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Oh I restated this not \
to sound like a broken vinyl record, but to underscore the issue I see combining the \
ideas. </div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">So if I need to \
traverse subset of topology which support given service and I want this service to be \
executed *on each node* on my flow aggregates why not to simply use Prefix-SID and \
flex-algo ? Why do we need MNA for it ? What is value add here ? Is there some delta \
or better advantage I am not seeing ? </div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Why don't you \
define your actions as part of given's flex-algo algorithm and do not use ISD \
nor PSD - just forward based on given flex-algo Prefix-SID ? </div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Is the concern in one \
octet limit of the number of algorithms ? If so that is why I wanted to better \
understand what physical forwarding differences one expects to see across such \
topologies. </div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: \
break-word;"><div><blockquote type="cite"><div dir="ltr"><div \
class="gmail_quote"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:small">Well in the vast \
majority of my deployment RAF tuple should not be modified anywhere in the network. \
</div></div></div></div></blockquote><div>It must be inserted at some point. And if \
MNA is used, then it must be inserted as \
well.<br></div></div></div></blockquote><div><br></div><div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Ok I was not \
considering "insertion" as "modification". \
</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"><div><blockquote type="cite"><div dir="ltr"><div \
class="gmail_quote"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:small">Hmmm didn't you \
say the other day that each LSR needs to parse the entire stack anyway in search for \
SPLs ? Remember my comment during the last meeting .. today label stack has no offset \
so you do not know what it contains till you parse it. Heavy ! \
</div></div></div></div></blockquote><div>This is true. Already happening for \
EL.<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">I have a bit of a \
different opinion here .. especially for the cases where nodes take the entire label \
stack as input for hashing without even recognizing that part of that is EL. \
</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"><div>The future of ANY feature is more about \
operator demand (i.e., $$$) than anything \
else.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">100%.</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Kind \
regards.</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small">Robert</div></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div></div>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic