Hi Stephane, I’ll take care of this asap. Sorry for the delay.
s. > On Sep 7, 2016, at 1:05 PM, stephane.litkow...@orange.com wrote: > > Hi Authors, > > Could you please check the comment’s below so we can continue to progress the > document ? > > Thanks ! > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of > stephane.litkow...@orange.com > Sent: Monday, August 22, 2016 15:14 > To: draft-ietf-spring-resiliency-use-ca...@ietf.org > Cc: spring@ietf.org; rt...@ietf.org > 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 > > > > > > > > > <image001.jpg> > > Stephane Litkowski > Network Architect > Orange/SCE/EQUANT/OINIS/NET > Orange Expert Future Networks > phone: +33 2 23 28 49 83 > mobile: +33 6 37 86 97 52 > stephane.litkow...@orange.com > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
