Hi all,
My colleague and I have discussed the relationship between link protection
schemes in Section 5.2 of the draft and "pinned node" scheme in Section 5.3,
and we would like to clarify this relationship.
If the link between the PLR and the pinned node fails, but the tail-end node
does not fail, the scheme in Section 5.2 protects all traffic traffic even if
the pinned node is the tail-end node of the SR LSP.
If the pinned node itself fails, the scheme defined SR LSPs for which the
pinned note is NOT the tail-end, but does NOT protect SR LSPs for which the
pinned node is the tail-end.
Does this mean that the PLR that supports both schemes SHOULD (or even MUST)
differentiate between failure of a link that connets it to a pinned node and
faikure of the pinned node itself in orfer to provide maximum possible
protection?
Your feedback will be highly appreciated.
Thumb typed by Sasha Vainshtein
From: [email protected]
Sent: Tuesday, July 30, 17:20
Subject: RE: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa
To: Shraddha Hegde, [email protected],
[email protected]
Hi Shraddha,
Thanks for your comments. The document is under RTGWG, then I’m adding rtgwg
list.
Please find some replies inline
From: Shraddha Hegde [mailto:[email protected]]
Sent: Monday, July 22, 2019 22:50
To: [email protected]; SPRING WG List
Subject: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa
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]).
[SLI] Agree, will fix it
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.
[SLI] §5.2 represents a link protection case , I agree that we don’t have to
look at the next segment and the text does not require it. However the current
structure could make think that we need.
I will propose a new text to address this.
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.
[SLI] The goal is to provide an expected result and not how the implementation
is done. Your text proposal looks reasonable and I will have a look on how to
provide a better wording for the text 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.
------------------------------------------------------------------------------------------------
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation.. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This
message and its attachments may contain confidential or privileged information
that may be protected by law; they should not be distributed, used or copied
without authorisation. If you have received this email in error, please notify
the sender and delete this message and its attachments. As emails may be
altered, Orange is not liable for messages that have been modified, changed or
falsified. Thank you.
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
__________________________________________________________________________________________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
