Hi Thomas,
I should have been more clear in my email.
The proposal/suggestion is to add the following to the IPFIX MPLS Label type
identifier registry:
* SR Prefix SID
* SR Adjacency SID
* SR Binding SID
* SR BGP Peering SID
* ... and so on
This helps identification of
Hi Jeff,
Thanks a lot for the review and feedback.
Please refer to my feedback to Ketan where elaborated more about why for label
protocol migrations IE 46 is useful.
* I'm not sure the FIB is the right place to collect this data though,
since most of meta-data has already been lost
Hi Ketan,
Thank you very much for the review and feedback.
* What or how much value be there on determining whether a SR Prefix SID
was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is
more important is that it is a Prefix SID. Hardly any deployments would be
I agree with Kethan and Jeff.
This draft is extending IPFIX defined in RFC 7011 7012 to support SR
segments over IP export.
Since SR-MPLS reuses the MPLS data plane, why would the existing IPFIX RFCs
also not support SR-MPLS without having to dig into IGP control plane
extensions as from an
Catching up on this thread as it is a interesting topic as FRR 1:N link
protection, node protection and path protection is critical to operators.
There are multiple somewhat orthogonal topics brought up in the discussion.
Excluding SR SFC from “bypass” capable node such for appliances such as
Jeff,
> This is very similar to RSVP-TE
I would rather differ on that statement.
See if you are using SR just for TE you are 100% right.
But if your SIDs embed additional local SR node processing functions this
suddenly becomes a completely different game. Let's keep this in mind in
this
In general, I agree with what Ketan said, what’s important - it is the value
that is being used in forwarding, even if multiple control plane entries exist,
think about IGP migrations, or LDP to SR, where more than 1 protocol could be
distributing the labels/SIDs. I’m not sure the FIB is the
< also copying Spring WG for their review/inputs >
Hi Thomas/All,
I have reviewed the draft and would like to share a different perspective.
What or how much value be there on determining whether a SR Prefix SID was
signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is
Ketan,
Looks like we are pretty much in sync here.
But let me just observe that I purposely did not mention about SR policies
as we are not able to signal the intent with the packets itself.
So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with
information if policies build
Hi Ketan,
While I completely agree with your note the consequences of it are pretty
sevre.
Unless we signal which prefix SID is protection eligible and which is not
how would other nodes know if they can protect it or not ?
It seems that today's safe thing is not to apply any node protection on
Hi Sasha,
The service node advertises its own Prefix SID. The service function that this
service node implements does not require any context (i.e. all packets arriving
at the node are subjected to that service). Therefore the service node does not
need to receive a packet with it's own Prefix
From what I have seen in this discussion, we have a number of different
views, all reasonable, mostly non-document. It would seem helpful to
write down our assumptions about meaning and get WG agreement??
Yours,
Joel
On 8/14/2020 10:54 AM, Alexander Vainshtein wrote:
Ketan, and all,
I have
Ketan, and all,
I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are
advertised with PHP can ONLY represent topological instructions in SR-MPLS -
because the advertising node will not receive them and therefore can hardly be
expected to associate any service function with
Hi all：
I think this draft is a useful topic，However, I think there is still space
for improvement in this solution. According to the solution in the draft, the
size of the context table of each node is the number of neighbors * (the number
of network nodes + the number of neighbors of
Hi Rajesh,
The prefix reachability is always signalled via the OSPFv2 Type 3/5/7 LSAs -
this is required for Algo 0 and 1 but also for Flex Algo for basic
reachability. These LSAs carry/include the IGP metric in them. The OSPFv2
Extended Prefix TLV is used to carry the Prefix SIDs - both algo
Hi Sasha,
If the service does not need any additional context (e.g. a firewall that just
applies locally configured default rules on it), then I don’t see why PHP could
not be done for a Prefix SID associated with a service node.
Also, I didn’t follow the point that you were trying to make
Hi all,
Regarding the statement "Prefix SID could be just a topological instruction or
may also be used to steer the flow to a node which is applying a service
function to it":
I think that in SR-MPLS a Node SID that is advertised with PHP aciton can be
safely considered as "just a
Hi All,
I believe this topic is relevant and something for the WG to adopt and work on.
I have some concerns though on it's applicability and more specifically it's
implications on existing deployments/use-cases. I've share the same on the
thread started by Joel on this specific aspect [1].
Hi All,
I would like to share a different perspective on this.
First, thanks to Joel for bringing up the discussion. Clearly we need a
well-defined applicability statement for determining applicability of
protection for segment used in an SR Policy. Some of this is captured in [1].
This is
Hi Zhenqiang Li,
Thanks for you review and sharing your comments. Please check inline below.
From: li_zhenqi...@hotmail.com
Sent: 05 August 2020 14:03
To: spring@ietf.org; draft-ietf-spring-segment-routing-policy
Subject: Comments on SR policy
Dear authors and all,
Please consider the
I support the adoption of this draft. It is Informational and provides set
of guidance to implementations.
Reading it quickly I think I am not seeing a section or exception in
handling cases where next sid is a binding sid.Skipping it may break the
game.
Also section 2.3 is IMO debatable. I know
21 matches
Mail list logo
