Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

[Gyan Mishra <[e-mail]>]

Hi Les

Thank you for the detailed explanation and progress on the ISIS extended
hierarchy draft which will be a substantial scalability improvement for
operators.

Responses In-line

Kind Regards

Gyan

On Fri, Oct 15, 2021 at 2:29 AM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> 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.

 Gyan> Understood

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.
    Gyan> Understood

> 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.
>
   Gyan> Understood.  Thank you for explaining.

> 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.

Gyan> Makes sense

> 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.

 Gyan> Understood

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.
   Gyan> Understood

> 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
>
>
   Gyan> Understood that a new modified scope for the short lived ephemeral
nature of the events being flooded

> 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.
>
> Gyan> Understood and agreed as this is a special flood use case suited for
> PSNP request/ack as LSP state synchronization is not required here.
>
> 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.
>
> Gyan> I  understand we require two new PDU types as this is a unique case
> that maybe leveraged in the future extensible for other event style
> notification future use cases.
>
> Some additional responses inline. If I did not specifically respond
> inline, please look to this introductory response for the answers.
>
>
>
> *From:* Lsr <[e-mail]> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, October 14, 2021 9:56 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>
> *Cc:* [e-mail]; Peter Psenak <ppsenak=[e-mail]>;
> Acee Lindem (acee) <acee=[e-mail]>
> *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. **😊*
>
     Gyan> Understood.

> *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.*
>
     Gyan> Understood that problem statement and solution is generally in
the same document.

> *But, this is a separate question which belongs in a separate thread – if
> need arises.*
>
>  Gyan> Understood
>
> 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
> <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.*
>
>  Gyan> Thank you for the detailed explanation!
>
> 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. *
>
>  Gyan> Understood.  In the PUA draft we have this detail and that had been
> the rub as it’s as you stated is in implementation space so can be
> omitted.  That would simplify the draft.
>
> 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.*
>
> * Gyan> Understood.  *
>
> *    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=
> [e-mail]> 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 <[e-mail]> On Behalf Of Acee Lindem (acee)
> > Sent: Wednesday, October 13, 2021 9:49 AM
> > To: Peter Psenak <ppsenak=[e-mail]>; [e-mail]
> > 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=[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*