Hi Les & Peter Thank you for the offer to join the Event Notification draft. I agree the Event Notification draft is an innovative solution to the problem statement presented by PUA using a new pulse PDU. I read through the draft and even though it’s a major IGP change to add event notification, using the RFC 7346 Flood scope LSP for the FS PDU does make it a possible solution.
As the PUA draft originally presented the problem statement and solution, could the draft be adopted and advanced as a problem statement draft instead of a solutions draft if WG adoption of the PUA draft as it stands is not possible. We have addressed the concerns mentioned on ML and during the last few presentations of PUA, however the draft has not gained traction from a solution side, but had indeed spurred interest in the real world problem space and finding of a possible solution with the now Event Notification draft. Few comments on the Event notification draft. RFC 7346 defines ISIS flooding scope LSPs and the PDU type field in ISIS PDU is encoded with 5 bit field yielding a maximum of 32 PDU types. In order to minimize the need to introduce additional PDU types in the future the new PDUs introduced in RFC 7346 allows for multiple flooding scopes to be associated with the same PDU. Therefore if new flooding scopes are required the same PDUs can be utilized. This Event Notification draft defines a new FS PDU type 8 IANA request. So it burns up PDU type of the maximum 32 available. This maybe a concern for future PDU types that LSR may want to use and is this a good use of defining a new PDU type. Section 4 states that all flood scopes are supported that FSP-LSP, FSP-PSNP, however FSP-CSNP is not required due to FSP LSP not being synchronized on adjacency establishment or GR. So all flood scopes are not supported however RFC 7346 states that all flood scopes must be supported by all new PDUs. Section 3 of RFC 7346 states that for all new PDUs that for new flood scopes all 3 PDUs below are required. The event notification draft states the FS-CSNP is not required however per RFC 7346 it is required. 3 <https://datatracker.ietf.org/doc/html/rfc7356#section-3>. Definition of New PDUs In support of new flooding scopes, the following new PDUs are required: o Flooding Scope LSPs (FS-LSPs) o Flooding Scope Complete Sequence Number PDUs (FS-CSNPs) o Flooding Scope Partial Sequence Number PDUs (FS-PSNPs) Section 4.2 of RFC 7346 states that synchronization of all FS-LSDBs is required so FS-CNSP for all supported scopes must be sent when new adjacency is formed per below. The event notification draft does not seem to be following the requirements of the FS PDU being utilized. 4.2 <https://datatracker.ietf.org/doc/html/rfc7356#section-4.2>. Operation on Point-to-Point Circuits When a new adjacency is formed, synchronization of all FS-LSDBs supported on that circuit is required; therefore, FS-CSNPs for all supported scopes MUST be sent when a new adjacency reaches the UP state. The Send Receive Message (SRM) bit MUST be set for all FS-LSPs associated with the scopes supported on that circuit. Receipt of an FS-PSNP with the U bit equal to 1 indicates that the neighbor does not support that scope (although it does support FS PDUs). This MUST cause the SRM bit to be cleared for all FS-LSPs with the matching scope, which are currently marked for flooding on that circuit. The bottom of section 5 needs to clearly state how the SCRLP TLV that is flooded by the ASBR and how all the internal routers within the area act on the SCRLP TLV to force the control plane convergence onto the alternative PE LPM or exact match FEC binding or SRv6 node-sid destination. That is exactly what the PUA does with the negative advertisement flood which forces all the internal routers in that area that receives the ASBR summary to set to bit bucket /dev/null any packets to the LPM thus forcing the convergence to the alternative PE. That is also why all the internal routers in the area acting on the PUA require a code upgrade. For the Event Notification to work the SCRLP TLV that is flooded somehow as it’s a different scope LSDB different LS PDU, it somehow has to update the instance MTID LSDB of LSP on the circuit. It’s a bit more tricky then just that as the internal router have the summary and traffic for the LSP is black holed on the ASBR doing the summarization. Somehow with the SCRLP TLV flooded to all internal routers, they have to perform a special action just like the action on the PUA negative advertisement, they have to force convergence so the internal routers in the area treats the SCRLP TLV like a PUA negative advertisement and stops using the summary route for the component prefix that is no longer reachable. “When an IS-IS L1/L2 router or an IS-IS Autonomous Boundary Router (ASBR) is performing prefix summarization and it loses the reachability to one or more previously reachable component(s) of the summary-prefix inside the area or domain for which the summarization is done, it MAY originate the SCRLP TLV to inform routers in other areas or domains about such summary component-prefix reachability loss. An originator of the SCRLP TLV chooses to advertise it in FSP-LSP with L1 flooding scope and/or FSP-LSP with L2 flooding scope. The IS-IS SCRLP TLV MAY be leaked between levels on L1/L2 router, subject to local policy of such L1/L2 router. IS-IS SCRLP TLV MUST NOT be leaked inside the area if the summary prefix carried in IS-IS SCRLP TLV (Summary Prefix, Summ-Pfx Length) is advertised from such area by L1/L2 router.“ Kind Regards Gyan On Wed, Oct 13, 2021 at 2:44 PM Les Ginsberg (ginsberg) <ginsberg= 40cisco....@dmarc.ietf.org> wrote: > This thread is becoming "diverse". > We are trying to talk about many different solutions (IGP, BGP, BFD) - all > of which may be useful and certainly are not mutually exclusive. > > If we can agree that an IGP solution is useful, then we can use this > thread to set a direction for the IGP solution - which seems to me to be > something we should do independent of whether the other solutions are also > pursued. > > With that in mind, here is my input on the IGP solutions: > > PUA > ------- > > For me, the solution has two major drawbacks: > > 1)It tries to repurpose an existing (and fundamental) Reachability > Advertisement into an UnReachability advertisement under certain conditions > > The interoperability risks associated with this make me very reluctant to > go down this path. > And the use of the same advertisement to indicate Reachability and > Unreachability is IMO highly undesirable. > > 2)The withdrawal of the "Unreachability Advertisement" after some delay > (which is necessary) remains problematic despite the authors attempts to > address thus > > Event Notification > ------------------------ > > This avoids the drawbacks of PUA and is flexible enough to handle future > and unforeseen types of notifications. > > I would like to extend the offer already made by Peter to the authors of > PUA to join us and work on the Event Notification draft. > The authors of PUA certainly deserve credit for raising awareness of the > problem space and it would be good to have them working with us on a single > IGP solution. > > But PUA is not an alternative that I can support. > > Les > > > -----Original Message----- > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) > > Sent: Wednesday, October 13, 2021 9:49 AM > > To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; lsr@ietf.org > > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF > > Extension for Event Notification" > > > > Hi Peter, > > > > See inline. > > > > On 10/13/21, 4:42 AM, "Peter Psenak" > > <ppsenak=40cisco....@dmarc.ietf.org> wrote: > > > > Hi Acee, > > > > On 12/10/2021 21:05, Acee Lindem (acee) wrote: > > > Speaking as WG Chairs: > > > > > > The authors of “Prefix Unreachable Announcement” have requested an > > > adoption. The crux of the draft is to signal unreachability of a > prefix > > > across OSPF or IS-IS areas when area summarization is employed and > > > prefix is summarised. We also have “IS-IS and OSPF Extension for > Event > > > Notification” which can be used to address the same use case. The > drafts > > > take radically different approaches to the problem and the authors > of > > > both drafts do not wish to converge on the other draft’s method so > it is > > > understandable that merging the drafts really isn’t an option. > > > > just for the record, I offered authors of "Prefix Unreachable > > Announcement" co-authorship on "Event notification" draft, arguing > the > > the event base solution addresses their use case in a more elegant > and > > scalable way. They decided to push their idea regardless. > > > > One solution to this problem would have definitely been better. > > > > > Before an adoption call for either draft, I’d like to ask the WG: > > > > > > 1. Is this a problem that needs to be solved in the IGPs? The use > case > > > offered in both drafts is signaling unreachability of a BGP > peer. > > > Could this better solved with a different mechanism (e.g., > BFD) > > > rather than flooding this negative reachability information > across > > > the entire IGP domain? > > > > we have looked at the various options. None of the existing ones > would > > fit the large scale deployment with summarization in place. Using BFD > > end to end to track reachability between PEs simply does not scale. > > > > It seems to me that scaling of BFD should be "roughly" proportional to > BGP > > session scaling but I seem to be in the minority. My opinion is based on > > SDWAN tunnel scaling, where BFD is used implicitly in our solution. How > > many other PEs does a BGP edge PE maximally peer with? > > Thanks, > > Acee > > > > > > Some people believe this should be solved by BGP, but it is > important to > > realize that while the problem statement at the moment is primarily > > targeted for egress PE reachability loss detection for BGP, the > > mechanism proposed is generic enough and can be used to track the > peer > > reachablity loss for other cases (e.g GRE endpoint, etc) that do not > > involve BGP. > > > > We went even further and explored the option to use completely out of > > band mechanism that do not involve any existing protocols. > > > > Simply, the advantage of using IGP is that it follows the existing > MPLS > > model, where the endpoint reachability is provided by IGPs. Operators > > are familiar with IGPs and know how to operate them. > > > > On top of the above, IGP event notification can find other use cases > in > > the future, the mechanism defined in draft is generic enough. > > > > > > > 2. Assuming we do want to take on negative advertisement in the > IGP, > > > what are the technical merits and/or detriments of the two > > approaches? > > > > we have listed some requirements at: > > > > https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event- > > notification-00#section-3 > > > > From my perspective the solution should be optimal in terms of > amount > > of data and state that needs to be maintained, ideally separated from > > the traditional LS data. I also believe that having a generic > mechanism > > to distribute events has it own merits. > > > > thanks, > > Peter > > > > > > > > We’ll reserve any further discussion to “WG member” comments on the > > two > > > approaches. > > > > > > Thanks, > > > Acee and Chris > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
