Drafts allow a B-Flag to be attached to the Adj-SID, which says that the
adjacency is “eligible for protection”. Such an adjacency may perhaps
also be interpreted as ineligible for SR policies that are particular that
only the selected adjacency must be used to reach the protected node.
This
Stewart,Lots of thanks for a prompt response.From my POV "normal" FRR (based on
LFA or RLFA) can be employed safely to protect against the"middle of a segment"
link and/or node failure without any impact on the policy. And it would not
respond to failure of the nodes (or links) that are part of
2. looks to be similar to 1+1 backup from the headend, which would be
the normal default, but you have to prevent the packet going down the
repair.
What would be nice would be to install a tailored backup hence:
3. Install a purpose built backup and somehow map to it on failure.
Both of
Ahmed,Regarding what was not clear:
As I see it, you have been carefully avoiding usage of the RFC 5331 language
(context-specific label spaces and context identifiers) in your SR-related
drafts. We (you and I) have already discussed this point wrt the SR anycast
draft.
Regarding the overlap:
That's good addition to the draft.
My comment is addressed.
Thx,
R.
On Tue, Nov 28, 2017 at 5:58 PM, Ahmed Bashandy (bashandy) <
basha...@cisco.com> wrote:
> Thanks for the the feedback
>
> The node "S" knows the SRGB and the adj-SIDs of the neighboring node "F".
> Hence if the new top label
Ahmed,I believe that the so-called protected Adj-SID simply means that if the
link that it represents fails, it can be replaced with the Node-SID of the node
at the remote end if the adjacency. It does not help at all if the downstream
node fails.
Sent from Yahoo Mail on Android
On Tue,
See inline
Ahmed
On 11/28/2017 8:04 AM, Alexander Vainshtein wrote:
Ahmed and all,
Two points:
1. From my POV your description of forwarding behavior when the link
S-->F fails is incomplete: the top label in the stack may be poppoed,
but it is not "forgotten", and the next exposed label is
Muthu,Please take a look at draft-hegde-spring-node-protection-for-sr-te-paths
that provides accurate descriprion of the requured DP behavior in the standard
terms (context-specifuc label spaces and context-identifying labels).
My 2c.
Sent from Yahoo Mail on Android
On Tue, Nov 28, 2017 at
Thanks for the the feedback
The node "S" knows the SRGB and the adj-SIDs of the neighboring node
"F". Hence if the new top label is not within these two sets, then the
node "S" will always be able to know that the node that failed is NOT a
midpoint but rather an egress point failure
I will
On Tue, Nov 28, 2017 at 5:34 PM, Ahmed Bashandy (bashandy) <
basha...@cisco.com> wrote:
> Hi,
>
> The behavior described in section 5.3 is clear:
> - The top label of incoming packet to node "S" is either a prefix SID
> owned by node "F" or an adjacency SID for (S,F)
> - If the link from node "S"
The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'A YANG Data Model for Virtual
Router Redundancy Protocol (VRRP)'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on
The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'A YANG Data Model for Routing
Information Protocol (RIP)'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this
Stewart,I understand your concern. However, as I see it, the alternatives to
local protection of a failed pinned node of a SR-TE LSP are somewhat limited:
1. You can wait (with no traffic) until failure of the pinned node is
recognized (e.g., fillowing IGP cobversion) and a new policy(that does
Ahmed and all,Two points:1. From my POV your description of forwarding behavior
when the link S-->F fails is incomplete: the top label in the stack may be
poppoed, but it is not "forgotten", and the next exposed label is looked up by
S in the context label space that is F-specific. I.e., if S
On 28/11/2017 12:04, Ahmed Bashandy (bashandy) wrote:
- The top label of incoming packet to node "S" is either a prefix SID
owned by node "F" or an adjacency SID for (S,F)
If it is an adjacency SID for (S,F) then you are violating the original
intent of the ingress PE which was to send
Hi Ahmed,
> - In a link-state envirnoment, node "S" knows the SRGB of node "F" as
well as all adjacency SIDs of node "F"
What you say is all true, but the way I read the question of this thread
seems to be what happens in the cases where node S has no clue of the new
top label. Say it was
I do not understand the question
Ahmed
On 11/23/2017 5:15 AM, Huzhibo wrote:
Because the normal FRR can not protect the designated node of SR-TE, a
method is provided to perform the label POP action by the penultimate
hop of the specified node replacing the specified node and forward it
to
Hi,
The behavior described in section 5.3 is clear:
- The top label of incoming packet to node "S" is either a prefix SID
owned by node "F" or an adjacency SID for (S,F)
- If the link from node "S" to node "F" is up, then the normal behavior
for node "S" is to apply penultimate hop popping
18 matches
Mail list logo
