Hi all, I've quickly read both drafts. In general, I don't think that I have spent enough time on the subject to provide any feedback on the list, but I've been suggested that some feedback is better than none. So providing some feedback for what it worth (2 cents).
I think that the use case is valid and worth working on. In general, I think that a single solution would be better than two or one per vendor. Especially since the design choice of using a set of standard routers in the area/clos (rather than a proprietary chassis or a proprietary switch matrix) is an indication that interoperability is seen as a benefit. Yet the outcomes of both solutions are different so maybe they may also be considered as independent. I'm personally fine with the approach chosen in draft-li-lsr-isis-area-proxy, which seems a good fit for the use case. I think that the document could better highlight, to the reader and especially to a casual network operator reader, that the use of one proxy LSP/node to represent all Inside Edge Router/whole introduces some tradeoff. IOW this is not magic/transparent. In particular I'm thinking of router capability TLV and more generally (new) TLV: when different inside (edge) nodes advertise different capabilities/TLV there is a difficulty in aggregating all for the proxy node/LSP. I appreciate that the authors have considered the Segment Routing (SR) case, but there are others, both past and future. For existing TLV/capabilities, maybe I would favor that the document define the behavior for all TLV/capability (along "you fix what you break"). I understand that this is a significant work and that different people may have different opinion. In particular I'm concerned when both primary and backup area leaders are from different implementations and switching from one to another would create a chang e in the characteristic of the proxy node, which could impact L2 routing (e.g. change in node admin tag). For future TLV/work, I think that the document should highlight that the behavior for proxy LSP need to be considered and specified. I've read draft-przygienda-lsr-flood-reflection. It is well written and works. Regarding flooding: a) IMHO I'm a bit scared with L2 flooding over tunnel: during L1 IGP convergence IP packet may be dropped including L2 LSP over IP tunnels. I don't feel that IS-IS is so good today to recover from lost LSP, in term of time required. The use of a TCP/SCTP tunnel may help, in which case there would be the question of not also using TCP for P2P adjacency, in order to handle flow control and congestion control and improve flooding speed. [1] proposes a modest improvement on faster recovery of lost LSP but this is also an individual document and will not completely remove the issue. b) the use of configured flood reflector in order to simplify the flooding topology may possibly be replaced by an existing flooding graph reduction e.g. [2] The properties are a bit different, such as the requirement for new feature on all nodes. However given the proposed L1 topology, we could also considerer that dynamic flooding would also be useful/used in L1. This would avoid the definition of another mechanism to reduce the flooding graph. Regarding L2 topology: a) the outcome and the scaling seem different between both drafts. Flood reflection keeps all L1/L2 edge nodes in the L2 topology. This allows for better description of those nodes capabilities in the L2 LSDB. However the gain in term of number of nodes/LSP in the LS2DB seem limited (only the spine nodes are hidden, while area proxy hide both spine and leaf nodes). So the main benefit seems to be related to flooding graph reduction rather than reduction of the L2 topology/LSDB. Yet we already have solution for reducing the flooding graph [2]. b) I think that the document should also discuss the TLV/capabilities advertised by the Flood Reflector in the L2 topology. In particular when Segment Routing is enabled. [1] https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-03#section-5 [2] https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding Regards, --Bruno _________________________________________________________________________________________________________________________ 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. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
