> On Feb 23, 2017, at 1:08 PM, Alexander Vainshtein > <alexander.vainsht...@ecitele.com> wrote: > > Hi all, > My colleagues and I have a couple of questions about some behavioral aspects > of IS-IS Segment Routing (SR) extensions. > > Suppose that we have an IS-IS domain where some routers run IS-IS with SR > extensions, and some routers run “vanilla” IS-IS for IPv4. > 1. What is supposed to happen when router A that runs IS-ISD without SR > extensions establishes an adjacency with router B that runs IS-IS with SR > extensions. Our expectations are that: > a. An adjacency between A and B would be allowed to progress to its > FULL state. Is that correct?
yes. > b. B will distribute all SR-related TLVs and sub-TLVs to A. Is that > correct? yes. > c. A will silently discard all SR-related TLVs and sub-TLVs it has > received from B. Is that correct? yes. However “discard” is not the right term. “ignore” is the right one. > 2. What is supposed to happen if IS-IS adjacency between A and B > reaches its FULL state, and then SR extensions are enabled in A. We expect > that: > a. It is possible to enable SR extensions in A without resetting its > adjacency with B (or any other adjacent router). Is that correct? yes. > b. Once B learns that SR capabilities of A have changed, it floods its > LSP database with all SR-related TLVs and sub-TLVs to A. Is that correct? LSDBs are not flooded again if there’s no change in adjacency state. Link state protocols work such that each router (SR capable or not) is supposed to keep the entire LSDB (even the TLVs it doesn’t understand). When suddenly SR is enabled, the router re-read its LSDB and process the SR TLVs/Sub-TLVs accordingly. > A brief scan of the draft did not yield answers to any of the questions above. because this is not related to SR but to the normal behavior of link-state routing. > Timely feedback would be very highly appreciated. hope this helps. s. > > Regards, and lots of thanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
