Gyan – Your comments are lengthy – I will start with some general explanation.
I believe that you are confused about the hierarchy between PDUs types and scopes. If that were more clear to you, I believe many of your comments would no longer need to be made. PDUs are a container for sending protocol information. Each PDU is associated with a specific scope and a specific flooding behavior. Base IS-IS has always supported scopes – but they are limited to Level-1 and Level-2 – and the scope is bound to the PDU type. When we wanted to introduce support for additional flooding scopes in RFC 7356, we could have simply extended the one-to-one mapping between a PDU type and a scope, but with the limited bits available for PDU type (5 bits) that could not scale. So, we invented new PDU types (FS-LSP, FS-PSNP, FS-CSNP) that supported a scope field in the header of the PDU. Now we could support a large number of scopes w only three new PDU types. It is important to note that the flooding behavior associated with the new PDU types defined by RFC 7356 is completely analogous to the base LSP, CSNP, PSNP PDU types. This is specified in RFC 7356. In the event notification draft, we are defining two new PDU types (FSP-LSP, FSP-PSNP). These new PDU types support scope in the same manner as their FS-xxx cousins from RFC7356. However, the flooding behavior associated with the new FSP-xxx PDUs is significantly different. This is discussed in https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.3 The PDU functionality specified in RFC 7356 does not apply to the new FSP-xxx PDUs. Therefore, suggesting that the lack of an FSP-CSNP is in violation of RFC 7356 is simply not correct. You seem to suggest below that we shouldn’t have used new PDUs but rather should have used new scopes in the event notification draft. But this would not scale. As the flooding behavior for FSP-xxx PDUs is different, we would have to encode that in the scope in order to differentiate from RFC 7356 flooding behavior. That would have meant duplicating every currently defined scope (we are now up to 81 defined scopes (out of a possible 127) based on https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04#section-11.4 ). using scope for this wouldn’t have scaled – and would have violated the current relationship hierarchy between PDU type and scope. Some additional responses inline. If I did not specifically respond inline, please look to this introductory response for the answers. From: Lsr <lsr-boun...@ietf.org> On Behalf Of Gyan Mishra Sent: Thursday, October 14, 2021 9:56 PM To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> Cc: lsr@ietf.org; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification" 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. [LES:] You are asking me to comment on a draft which does not yet exist – which doesn’t seem fair. 😊 I will say that it isn’t clear to me why, in this particular case, we would need two documents (problem statement and protocol extensions). Historically one document has sufficed for both in many cases. But, this is a separate question which belongs in a separate thread – if need arises. 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. [LES:] I have explained above why using new PDUs was chosen. In addition to what I stated above, I would add that you might want to take a look at https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-extended-hierarchy-04. This introduces even more new PDU types (7 new ones I believe) – but the good news is it also extends PDU type to an 8 bit field (the 3 MSBs were Reserved and never used for anything – so this is possible). 😊 The same document also introduces lots more scopes. 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. [LES:] Actually we don’t – and we shouldn’t. 😊 Existing IGP specifications do NOT specify how an implementation uses the output of an SPF. What happens when the same route is learned from two different sources, how redistribution is done, etc. No need to do so here. 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. [LES:] The SCRLP TLV includes MTID as part of the advertisement for each of the prefixes it advertises. See Section 5. This is analogous to how it is done in prefix reachability advertisements. Les 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<mailto: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<mailto: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<mailto:40cisco....@dmarc.ietf.org>>; > lsr@ietf.org<mailto: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<mailto: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<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
