Hi Authors, Could you please check the comment's below so we can continue to progress the document ?
Thanks ! From: spring [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, August 22, 2016 15:14 To: [email protected] Cc: [email protected]; [email protected] Subject: [spring] Shepherd review of draft-oetf-spring-resiliency-use-cases 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. _________________________________________________________________________________________________________________________ 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
