Hi,
I have been selected as Shepherd for this document, and as part of my review I
have several comments that you will find below :
General :
Is it a requirement document ? If yes, it would be good to mention it. The
document states requirements multiple times.
Abstract :
The abstract is really short, would be good to enhance it with what is exactly
described.
In Section 1, there should be an issue with the XML file as the hypertext link
is missing at : "We discuss two different approaches to provide ..., in Section
3". Hyperlink missing for "Section 3".
In Section 2,
It would be good to state in the example that the paths must not be protected
by any local repair techniques. Example : "The two paths are made disjoint
using the SPRING architecture and must not be protected by any local repair
techniques".
As a requirement, the two paths must be disjoint (link or node, or srlg), this
has some impacts on the path expression : using a node-SID would be a bad idea
as there is no guarantee. It would be good to mention that the solution must
take care of this.
It would be easier to state that path T1 is primary and T2 is backup instead of
: "When T1 is up, the packets of the PW are sent on T1".
Why not using the following text :
"T1 is programmed as primary forwarding entry while T2 is a backup entry. In
nominal state, PW traffic is carried over T1. When T1 fails, the PW traffic is
switched on T2".
Before telling that the solution for end-to-end liveness is out of scope, it
would be good to state that it is mandatory to have such mechanism to make the
solution work. Is it a SPRING path liveness check or service liveness check ?
It would be good to tell who is in charge of the detection and path switchover
? is it LSP ingress, is it a node outside SPRING network ? If there are
multiple options, please tell it.
I would propose to change the last sentence to highlight the two requirements
in case we need SPRING path liveness check :
"From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end
liveness check of SPRING based LSPs. In addition, it MUST provide a way to
create LSPs that must not be protected by local repair techniques."
Globally this section looks confusing to me. End to end protection could be
achieved in multiple ways, for example :
- Having a dumb network that only provides disjoint non protected path and
having end-to-end probes at service level that would help an external component
to switchover traffic. Provider network is not aware of the protection done. In
your figure we can add A' and Z', and we establish two disjoint LSPs (A->Z and
A'->Z'). Customer is dual meshed to A/A' and Z/Z' and is managing liveness
check and switchover (network is not involved).
- Having primary/backup like approach : two disjoint LSPs from A->Z , A
programs one in FIB. A provides OAM on the LSP. When primary LSP fails, the
second one is installed in FIB.
- Having FRR like approach : two disjoint LSPs from A->Z , A programs both in
FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enable
traffic switchover in a very short time.
The current text is not really clear on the proposed approach. Maybe another
one ?
Section 3
s/the backup path computation should/the backup path computation SHOULD/
s/in any topology/in any topology./
s/by the IGP/by the IGP./
Section 3.1
"ending at the protected nexthop", that's true only for link protection, but
not possible in case of node protection. This sentence is a generic one and is
not specific to link protection case.
I cannot parse : "so as to bypass the failed component ..."
I would propose something like :
"One way to provide local repair is to enforce a failover along the shortest
path around the protected component. In case of link protection, the point of
local repair will create a bypass avoiding the protected link and merging back
to primary path at the nexthop. In case of node protection, the bypass will
avoid the protected node and merge back to primary path at the next-nexthop."
What about SRLG case ?
"In our example, C protects Z", protects for what ? link / node /srlg failure ?
proposed text : "In our example, C protects destination Z for a failure CD link"
"that it initially reaches via CD", yes and also using CH because of ECMP, it
would be better to change the example to disable ECMP. There are multiple ECMPs
that would not help the reading. Even A as ECMP to Z.
Section 3.2
"providing a repair for the destination based on shortest path state for that
destination". Why using "state" ?
Again : "In our example, C protects Z", protects for what ? link / node /srlg
failure ?
You have again ECMP starting from A, and at other nodes that complexifies the
example.
Why not talking about pros/cons between approaches ?
Section 4.
SRLG was mentioned as a requirement in Section 3. So why considering it as a
more high level constraint ?
If SRLG is management-free, please change your example with another constraint
type (bandwidth for example).
You can refer to RFC7916 as an example of managed computation. Similar approach
can be used here.
Section 4.1
Is the path {CG,GH,HD} computed automatically or putted manually ? Please be
clear on what must be done.
Section 4.2
This case is a bit strange. The goal is to use shortest path protection to the
destination but here we enforce a non shortest path, so the name is no more
applicable. It is more a per-destination protection tweaking. Again how is it
done, configured manually per destination or group of destinations ? Do you
have requirements here ?
Section 5
First sentence is hard to read (it works but hard to read). Is it possible to
make it simpler ? For example, "when a topology change occurs in a network,
transient inconsistencies of router FIBs can occur."
Could you point to relevant RFCs/drafts on microloops to help readers that are
interested by more information on the subject.
You could tell that those micro-loops are breaking local repair techniques
preventing 50msec restoration.
Could you provide an example on how SPRING can prevent loops ? (as you done for
protection cases)
Section 6.
Could you rename the title to be more explicit : co-existence of what ?
Section 8.
You also provide requirements, and you have example of manageability
requirements (revert ability for path protection, managed path) ...
Please state clearly that the manageability requirements provided in this
document must be addressed by the solution documents. Could you summarize the
manageability requirements here ?
Best Regards,
Stephane
[Orange logo]<http://www.orange.com/>
Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email protected]<mailto:[email protected]>
_________________________________________________________________________________________________________________________
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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
