Dear Authors
I have the below comments on the draft.
1. Section 1.Introduction
"This provides a major improvment compared to LFA
([RFC5286]) and remote LFA ([RFC7490]) which cannot be applicable in
some topologies ([RFC6571])."
Change to
This provides a major improvement compared to LFA
([RFC5286]) and remote LFA ([RFC7490]) which cannot provide
complete protection coverage in
some topologies ([RFC6571]).
2. I suggest to add a new section for building repair segments .
The text appears randomly and it is not very readable.
Suggest to re-arrange as below
---------------------------------------------------------------------------------------
5. Building Repair lists
The repair list consist of node segments and adjacency segments
which represents the
protection path from PLR to the destination.
o The active adjacency segments MUST be popped and the repair-list MUST be
inserted
at the head of the list.
o The active node segments MUST be popped and repair-list inserted as the
last segment of repair list,
If the repair list ends with an adjacency segment terminating on
the tail-end of the
active segment, and if the active segment has been signalled
with penultimate hop popping.
o The active node segment MUST be retained as the last segment in the
repair-list if the
active node segment has been signaled with ultimate hop popping.
o If the SRGB at the Q node is different from the SRGB at the PLR,
then the active segment (before the insertion of the repair list)
MUST be updated to fit the SRGB of the Q node.
-----------------------------------------------------------------------------------------------
3. Protecting segments
It is not clear what do the section 5.2.1 and 5.2.2 represent.
Are these for link-protection cases? You don't have to look into next label
for link-protection cases.
The mid-point node failure section 5.3 addresses node as well adjacency SID
cases so 5.2.1 and 5.2.2 need not talk about node protection.
4.
Modern routing architectures have separate control plane and data plane.
section 5.3 language seem to suggest a lot of contol plane like processing in
the forwarding plane.
The entire description has a MUST term which mandates implementing expensive
operation in forwarding plane.Suggest to add below text in section 5.3 and also
change all MUST in 5.3.1 and 5.3.2
to non-normative should.
I have copied the entire 5.3 section with suggested changes highlighted in bold
-------------------------------------------------------------------------------------------------
5.3
Section 5.3.1 and 5.3.2 describe the processing for incoming Node and
Adjacency SIDs
when the next label in the packet is either a node/adj-sid.
The description below is intended to specify the forwarding behavior required
for node protection.
The description should not be interpreted as limiting the possible
implementations of this forwarding behavior.
An implementation complies with the description below as long as the externally
visible forwarding behavior produced
by the implementation is the same as that described below.
5.3.1. Protecting {F, T, D} or {S->F, T, D}
This section describes the protection behavior of S when all of the
following conditions are true:
1. the active segment is a prefix SID for a neighbor F, or an
adjacency segment S->F
2. the primary interface used to forward the packet failed
3. the segment following the active segment is a prefix SID (for
node T)
4. node protection is active for that interface.
In such a case, the PLR should:>>>>>>>>Change to non-normative should
1. apply a NEXT operation; the segment F or S->F is removed
2. Confirm that the next segment is in the SRGB of F, meaning that
the next segment is a prefix segment, e.g. for node T
3. Retrieve the segment ID of T (as per the SRGB of F)
4. Apply a NEXT operation followed by a PUSH operation of T's
segment based on the SRGB of node S.
5. Look up T's segment (based on the updated label value) and
forward accordingly.
5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D}
This section describes the protection behavior of S when all of the
following conditions are true:
1. the active segment is a prefix SID for a neighbor F, or an
adjacency segment S->F
2. the primary interface used to forward the packet failed
3. the segment following the active segment is an adjacency SID (F-
>T)
4. node protection is active for that interface.
In such a case, the PLR should:>>>>>>>>>Change to non normative "should"
1. Apply a NEXT operation; the segment F or S->F is removed
2. Confirm that the next segment is an adjacency SID of F, say F->T
3. Retrieve the node segment ID associated to T (as per the set of
Adjacency Segments of F)
4. Apply a NEXT operation on the next segment followed by a PUSH of
T's segment based on the SRGB of the node S.
5. Look up T's segment (based on the updated label value) and
forward accordingly.
------------------------------------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
