Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les, 

> On Mar 28, 2023, at 20:53, Les Ginsberg (ginsberg)  wrote:
> 
> Acee -
> 
> So your proposal is to have the neighbor of the restarting router be 
> responsible for ensuring that the Router LSA updates are done in the proper 
> order.
> I agree this can work as well.
> 
> I still think there is one element missing from your proposal i.e., 
> guaranteeing that the Router LSA update from the restarting router is flooded 
> before (or at least in the same Link State Update packet) as the updated 
> Router LSA from the neighbor - and that this order is maintained at each 
> flooding hop throughout the network.
> This is likely to happen - but without some delay between flooding the 
> updated Router LSA from the restarting router and the updated Router LSA on 
> the neighbor there is still some risk.

See my response to Liyan. If we leave the Router-LSA on the neighbor’s Link 
State Request list when a less recent version is received, the adjacency will 
not go to full until the more-recent version is received. This will handle case 
where the restarting router’s Router-LSA is the last or only element in the 
list. 

Thanks,
Acee



> 
>   Les
> 
>> -Original Message-
>> From: Acee Lindem 
>> Sent: Tuesday, March 28, 2023 2:19 PM
>> To: Les Ginsberg (ginsberg) 
>> Cc: Liyan Gong ; Tony Przygienda
>> ; chen.mengxiao ; lsr
>> ; Weiqiang Cheng ;
>> linchangwang 
>> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
>> suppress-00.txt
>> 
>> Hi Les
>> 
>>> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
>>  wrote:
>>> 
>>> (For some reason, email from you now goes into my Junk folder – delaying
>> my response. )
>>> Acee –
>>> Consider the simple topology:
>>> A---B---C
>>> A is the restarting router.
>>> C represents “the rest of the network” attached to B.
>>> Router A goes down.
>>> Adjacency on B to A goes down.
>>> The LSPDB on C now has:
>>> Router LSA B w no adjacency to A
>>> Router LSA A w adjacency to B (stale)
>>> A comes up – adjacency between A and B forms.
>>> What happens next on C (and all the routers downstream) depends on
>> order.
>>> Case #1
>>> New Router LSA B w adjacency to A arrives.
>> 
>> With the change I proposed, Router B will not become adjacent to Router A
>> without getting an updated version of Router A’s LSA that doesn’t include
>> the link to Router B.
>> 
>> 
>> 
>>> At this point, C believes there is two-way connectivity between A and B
>> because of the presence of the stale Router LSA A
>>> New Router LSA A w no adjacency to B arrives
>>> Now C has the up to date information
>>> Case #2
>>> New Router LSA A w no adjacency to B arrives
>>> New Router LSA B w adjacency to A arrives
>>> C still sees no 2way connectivity between A and B
>>> The reason you need to control the ordering is to prevent Case #1 from
>> occurring.
>>> Yes, this is a transient – LSPDB will eventually converge – but the duration
>> of “eventually’ depends on scale.
>>> SA bit can be used to prevent Case #1 from ever occurring – or at least
>> make it very unlikely.
>> 
>> The change I proposed will prevent it as well. Router B will request Router 
>> A’s
>> LSA and Router A will respond with the new version which doesn’t have the
>> link to Router B. Router B will respond with the more-recent version (see 
>> this
>> excerpt from RFC 2328 13.3):
>> 
>> 
>> 
>>  (8) Else, the database copy is more recent. If the database copy
>>   has LS age equal to MaxAge and LS sequence number equal to
>> MaxSequenceNumber, simply discard the received LSA without
>>   acknowledging it. (In this case, the LSA's LS sequence number is
>>   wrapping, and the MaxSequenceNumber LSA must be completely
>>   flushed before any new LSA instance can be introduced).
>>   Otherwise, as long as the database copy has not been sent in a
>>   Link State Update within the last MinLSArrival seconds, send the
>>   database copy back to the sending neighbor, encapsulated within
>>   a Link State Update Packet. The Link State Update Packet should
>>   be sent directly to the neighbor. In so doing, do not put the
>>   database copy of the LSA on the neighbor's link state
>>   retransmission list, and do not acknowledge the received (less
>> recent)
>> LSA instance.
>> 
>> 
>> Once Router A receives a more recent version and processed as described in
>> section 13.4:
>> 
>> 
>>  However, if the received self-originated LSA is newer than the
>>  last instance that the router actually originated, the router
>>  must take special action. The reception of such an LSA
>>  indicates that there are LSAs in the routing domain that were
>>  originated by the router before the last time it was restarted.
>>  In most cases, the router must then advance the LSA's LS
>>  sequence number one past the received LS sequence number, and
>>  originate a new instance of 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming
remote is the unplanned bouncer, in chain example B local A remote)
advertises its LSA with the link failed and that gets flooded immediately
(I assume the link local-remote is *not* a minimal cut in the topology so
there are paths to flood the whole network without the link coming up again
unlike the 3 router example) and then local does NOT advertise adjacency
until it's full no matter what which will take a bit of time. So even if
floods high-version remote LSA overriding the remote's initial low-version
LSA the bidirectional check fails as Acee points out. Then remote overrides
and remote and local only flood LSAs with adjacency in them after full
which takes some time in any case.  Adding additional signalling and
interdependencies between hellos and LSA origination seems to me shooting
at pretty little birds with canons somewhat due to involved
interdependencies.

I probably repeat partially what Acee said but it's my 2c

-- tony

On Wed, Mar 29, 2023 at 9:53 AM Les Ginsberg (ginsberg) 
wrote:

> Acee -
>
> So your proposal is to have the neighbor of the restarting router be
> responsible for ensuring that the Router LSA updates are done in the proper
> order.
> I agree this can work as well.
>
> I still think there is one element missing from your proposal i.e.,
> guaranteeing that the Router LSA update from the restarting router is
> flooded before (or at least in the same Link State Update packet) as the
> updated Router LSA from the neighbor - and that this order is maintained at
> each flooding hop throughout the network.
> This is likely to happen - but without some delay between flooding the
> updated Router LSA from the restarting router and the updated Router LSA on
> the neighbor there is still some risk.
>
>Les
>
> > -Original Message-
> > From: Acee Lindem 
> > Sent: Tuesday, March 28, 2023 2:19 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Liyan Gong ; Tony Przygienda
> > ; chen.mengxiao ; lsr
> > ; Weiqiang Cheng ;
> > linchangwang 
> > Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> > suppress-00.txt
> >
> > Hi Les
> >
> > > On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > (For some reason, email from you now goes into my Junk folder –
> delaying
> > my response. )
> > >  Acee –
> > >  Consider the simple topology:
> > >  A---B---C
> > >  A is the restarting router.
> > > C represents “the rest of the network” attached to B.
> > >  Router A goes down.
> > > Adjacency on B to A goes down.
> > > The LSPDB on C now has:
> > >  Router LSA B w no adjacency to A
> > > Router LSA A w adjacency to B (stale)
> > >  A comes up – adjacency between A and B forms.
> > > What happens next on C (and all the routers downstream) depends on
> > order.
> > >  Case #1
> > > New Router LSA B w adjacency to A arrives.
> >
> > With the change I proposed, Router B will not become adjacent to Router A
> > without getting an updated version of Router A’s LSA that doesn’t include
> > the link to Router B.
> >
> >
> >
> > > At this point, C believes there is two-way connectivity between A and B
> > because of the presence of the stale Router LSA A
> > > New Router LSA A w no adjacency to B arrives
> > > Now C has the up to date information
> > >  Case #2
> > > New Router LSA A w no adjacency to B arrives
> > > New Router LSA B w adjacency to A arrives
> > > C still sees no 2way connectivity between A and B
> > >  The reason you need to control the ordering is to prevent Case #1 from
> > occurring.
> > > Yes, this is a transient – LSPDB will eventually converge – but the
> duration
> > of “eventually’ depends on scale.
> > >  SA bit can be used to prevent Case #1 from ever occurring – or at
> least
> > make it very unlikely.
> >
> > The change I proposed will prevent it as well. Router B will request
> Router A’s
> > LSA and Router A will respond with the new version which doesn’t have the
> > link to Router B. Router B will respond with the more-recent version
> (see this
> > excerpt from RFC 2328 13.3):
> >
> >
> >
> >   (8) Else, the database copy is more recent. If the database copy
> >has LS age equal to MaxAge and LS sequence number equal to
> >  MaxSequenceNumber, simply discard the received LSA without
> >acknowledging it. (In this case, the LSA's LS sequence number
> is
> >wrapping, and the MaxSequenceNumber LSA must be completely
> >flushed before any new LSA instance can be introduced).
> >Otherwise, as long as the database copy has not been sent in a
> >Link State Update within the last MinLSArrival seconds, send
> the
> >database copy back to the sending neighbor, encapsulated
> within
> >a Link State Update Packet. The Link State Update Packet
> should
> >be sent directly to the neighbor. In so doing, do not put the
> >database copy 

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[bruno.decraene]

Les, all 
 
> From: Les Ginsberg (ginsberg)  
> 
> Chris -
> 
> 
> However, that is the missing piece, so it works if we also add a capability 
> bit. If we have the capability bit you now know which routers are processing 
> the container TLV and which aren't. That should be enough info to route 
> correctly.
> 
> Using a container TLV *and* a capability bit is not a free lunch, but it 
> should work to allow incremental deployment safely. If that's something we 
> want as a WG.
> 
> 
> No - this does not work.
> Customer deploys some features. They expect all routers in the network to be 
> able to correctly calculate topology and correctly forward for the features 
> they support.
> They do not deploy a feature and expect only a subset of the routers in the 
> network that are configured to support the feature to correctly calculate 
> paths.
> 
> There is no way to successfully support incremental deployment.

[Bruno]
1) globally consistent TLV or not
Probably the discussion we could make a distinction between:
- a- TLVs which are required to be consistent (typically the one involved in 
distributed SPF e.g. IP and IS reachability)
- b- TLVs which are not (e.g. SRv6 locators for algo 0 & 1, but there are 
probably others easier e.g. local adjacency SIDs for SR-MPLS)

For "a" there is no way to do incremental deployment. So it's either relying on 
careful deployment (and implementation) or relying on a capability. Both 
solution seems equal on this.
For "b" the big TLV will allow to deploy larger TLV without impacting legacy 
implementation. That's a benefit.

2) failing versus failing
Even when we need global consistency , there may be multiple failure modes to 
consider.
- One is not achieving global consistency, which will trigger adverse 
consequences. E.g. persistent forwarding loops for some path for data involved 
in SPF computations. Both solutions have the same properties 
- One is that the new advertisement is not correctly understood by legacy 
implementation and confuse them. This may trigger additional issues. E.g. 
larger set of inconsistencies as the first TLV instance/part may not become 
inconsistent anymore. Also, unfortunately, it's not unheard that some 
implementation are light on the error handling part (e.g. "undefined behavior", 
IS-IS process crash). In that regards, big-tlv seems to have an advantage in 
that legacy implementation are not impacted and everyone have a consistent view 
of the first TLV part.
. 

> > >>>We are not naïve - we understood very well that if not all routers in the
> > network supported at least reception of MP TLVs that there would be
> > deployment issues.

[Bruno]
Did network operators had the opportunity to comment on these deployment issues 
and discuss the involved trade-off?
I have never assumed that you were naïve and I don't feel that this was implied 
in the original email. IMO the question is that different person may have 
different perspective (which is just fine). So if the decision is taken by a 
single set of persons having a similar perspective, it's likely that the 
outcome optimization be only local.  e.g. pushing back the issue/complexity on 
the network operation side versus on the design/implementation side.

--Bruno

> 
> I already gave an example in my comments below:
> 
> > >> > [LES:] Consider the following simple example.
> > >> >
> > >> > Node A needs to send 10 sub-TLVs about a particular object –
> > >> > requiring more than 255 bytes to be sent.
> > >> >
> > >> > Some nodes in the network do not support reception of more than 255
> > >> > bytes/object. Consider two such nodes.
> > >> >
> > >> > Node B, based on the local configuration, needs to be able to receive
> > >> > sub-TLVs 1,3,5,7,9 from A.
> > >> >
> > >> > Node C, based on local configuration, needs to be able to receive
> > >> > sub-TLVs 2,4,6,8,10 from A.
> > >> >
> > >> >
> > >> >
> > >> > There is no way that A can advertise all 10 sub-TLVs in a way which
> > >> > allows both B and C to correctly process the sub-TLVs they require.
> > >> >
> 
   > Les
> 
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Tuesday, March 28, 2023 9:52 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Christian Hopps ; Huaimo Chen
> > ; draft-chen-lsr-isis-big-tlv.auth...@ietf.org;
> > lsr@ietf.org
> > Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> > 
> > 
> > "Les Ginsberg (ginsberg)"  writes:
> > 
> > > Chris -
> > >
> > > Please see inline - I'll try to conform to your request about ">>>" 
> > > quoting -
> > > but given that this style does not identify who made the comment, I have
> > found
> > > in the past that this style becomes very hard to follow after a couple of
> > > replies.
> > > Though perhaps that could be said of any style. 
> > 
> > Well in the ">>>" style my text that you were quoting would have been
> > 
> > "> like this"
> > 
> > and yours would not have anything preceding it.. like mine is here.
> > 
> > anyway, it's a losing 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

Acee -

So your proposal is to have the neighbor of the restarting router be 
responsible for ensuring that the Router LSA updates are done in the proper 
order.
I agree this can work as well.

I still think there is one element missing from your proposal i.e., 
guaranteeing that the Router LSA update from the restarting router is flooded 
before (or at least in the same Link State Update packet) as the updated Router 
LSA from the neighbor - and that this order is maintained at each flooding hop 
throughout the network.
This is likely to happen - but without some delay between flooding the updated 
Router LSA from the restarting router and the updated Router LSA on the 
neighbor there is still some risk.

   Les

> -Original Message-
> From: Acee Lindem 
> Sent: Tuesday, March 28, 2023 2:19 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Liyan Gong ; Tony Przygienda
> ; chen.mengxiao ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> suppress-00.txt
> 
> Hi Les
> 
> > On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > (For some reason, email from you now goes into my Junk folder – delaying
> my response. )
> >  Acee –
> >  Consider the simple topology:
> >  A---B---C
> >  A is the restarting router.
> > C represents “the rest of the network” attached to B.
> >  Router A goes down.
> > Adjacency on B to A goes down.
> > The LSPDB on C now has:
> >  Router LSA B w no adjacency to A
> > Router LSA A w adjacency to B (stale)
> >  A comes up – adjacency between A and B forms.
> > What happens next on C (and all the routers downstream) depends on
> order.
> >  Case #1
> > New Router LSA B w adjacency to A arrives.
> 
> With the change I proposed, Router B will not become adjacent to Router A
> without getting an updated version of Router A’s LSA that doesn’t include
> the link to Router B.
> 
> 
> 
> > At this point, C believes there is two-way connectivity between A and B
> because of the presence of the stale Router LSA A
> > New Router LSA A w no adjacency to B arrives
> > Now C has the up to date information
> >  Case #2
> > New Router LSA A w no adjacency to B arrives
> > New Router LSA B w adjacency to A arrives
> > C still sees no 2way connectivity between A and B
> >  The reason you need to control the ordering is to prevent Case #1 from
> occurring.
> > Yes, this is a transient – LSPDB will eventually converge – but the duration
> of “eventually’ depends on scale.
> >  SA bit can be used to prevent Case #1 from ever occurring – or at least
> make it very unlikely.
> 
> The change I proposed will prevent it as well. Router B will request Router 
> A’s
> LSA and Router A will respond with the new version which doesn’t have the
> link to Router B. Router B will respond with the more-recent version (see this
> excerpt from RFC 2328 13.3):
> 
> 
> 
>   (8) Else, the database copy is more recent. If the database copy
>has LS age equal to MaxAge and LS sequence number equal to
>  MaxSequenceNumber, simply discard the received LSA without
>acknowledging it. (In this case, the LSA's LS sequence number is
>wrapping, and the MaxSequenceNumber LSA must be completely
>flushed before any new LSA instance can be introduced).
>Otherwise, as long as the database copy has not been sent in a
>Link State Update within the last MinLSArrival seconds, send the
>database copy back to the sending neighbor, encapsulated within
>a Link State Update Packet. The Link State Update Packet should
>be sent directly to the neighbor. In so doing, do not put the
>database copy of the LSA on the neighbor's link state
>retransmission list, and do not acknowledge the received (less
> recent)
>  LSA instance.
> 
> 
> Once Router A receives a more recent version and processed as described in
> section 13.4:
> 
> 
>   However, if the received self-originated LSA is newer than the
>   last instance that the router actually originated, the router
>   must take special action. The reception of such an LSA
>   indicates that there are LSAs in the routing domain that were
>   originated by the router before the last time it was restarted.
>   In most cases, the router must then advance the LSA's LS
>   sequence number one past the received LS sequence number, and
>   originate a new instance of the LSA.
> 
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> 
> >Les
> >  From: Acee Lindem 
> > Sent: Tuesday, March 28, 2023 10:02 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Liyan Gong ; Tony Przygienda
> ; chen.mengxiao ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> > Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> suppress-00.txt
> >  Les,
> >
> >
> > On Mar 28, 2023, at 12:45, Les Ginsberg (ginsberg) 
> wrote:
> >  Acee –
> >  I will leave it to you and the 

Re: [Lsr] PUA Converge Efforts(LSInfinity or MaxAge)

[Aijun Wang]

Hi, All:As discussed within the list, we have noticed there will be confusion for the usage/implementation/deployment of LSInfinity. Because the main motivation for this field is to let the legacy nodes bypass the PUA/UPA message, we propose use the MaxAge of the LSA to accomplish such task. The reasons are the following:1) RFC2328 has described the similar results for these two fields:   (1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.2) The PUA/UPA message is one PULSE message, it should not exist within the network long time. Exploitable this value is straightforward to be implemented/deployed.Aijun WangChina TelecomOn Mar 27, 2023, at 15:02, Aijun Wang  wrote:Hi, Bruno:Let me answer some questions from you based on the current PUA solution. From the inline replies, we think the converged draft should be based on PUA draft.Aijun WangChina TelecomOn Mar 27, 2023, at 14:00, bruno.decra...@orange.com wrote:









Hi
authors,
 
Please find below some questions.
 

Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1 with MAX metric.
 Is this prefix reachable or unreachable (or both)?[WAJ] This is the network partition scenario that we mentioned in the meeting, and also in the document.(UPA has no similar solution now)According to our considerations, the prefixes IP1 will be reachable via ABR1. This is the right answer for such situation.The contents for such situations are described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-11#section-4“When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2, along with the PUAM message for the associated prefixe from these ABRs, the ABR that can reach the PUAM prefix should advertise the specific route to this prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUAM prefix, to reach the prefix that advertised in PUAM message.”¶Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2 advertises
 IP1 with MAX metric does this count as UPA? (i.e. may a router advertise unreachability for a prefix advertised by another router?)[WAJ] In principle, the ABR that doesn’t send the summary address shouldn’t send the PUA/UPA message. So, normally, the ABR2 will not send such message with the MAX metric set.If it is sent out by ABR2 by any way, but not by ABR1, then it belongs to again the partition scenario(the receiver will know that it can reach such prefix via ABR1, not ABR2)Can you clarify the scope of the UPA signaling? E.g. if TLV 135 advertises prefix
 IP1 with MAX metric
does this signal UPA for all
FlexAlgo?If IS-IS Flexible Algorithm Prefix Metric is advertised, is MAX metric to be advertised
 in the main TLV, or per FAPM sub-TLV, or both? Can you specify the behavior in case on “inconsistencies”?Does this signal UPA If the summary address (aka the less specific prefix) is advertised
 in a different IS-IS instance or in a different protocol (e.g. OSPF, BGP…)?[WAJ] I think Peter can explain the above questions more clearly. Anyway, this is the reason that we mentioned during the meeting that we shouldn’t design the solution that relying heavily on the LSInfinity exploration.The less to depend on it, the better. That is the reason that we introduce the capabilities negotiation procedure(UPA based solution cannot be deployed without the dependency on the LSInfinity in future, this is unacceptable. The rely on the LSInfinity, or other bypass method should be only temporary)——once all the routers within the area support such capabilities, such feature will have no relation with the LSInfinity which may be used in other scenarios.
Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will trigger BGP PIC edge
 for 255 /32)[WAJ] In principle, the ABR send only the PUA information for /32 prefix. As stated in the PUA draft:Prefix Unreachable Announcementdatatracker.ietf.orgBased on such information, the ABR will only advertise the PUAM message when the tracked prefixes(for example, the loopback addresses of PEs that run BGP) that within the summary address is missing.For UPA of SRv6 locators for algo 0 or 1, is the MAX METRIC to be advertised for
 TLV 27 or 236 or both? Can you specify the behavior in case on “inconsistencies”?“a summary address which covers the prefix is being advertised by the ABR/ASBR”.
 For IS-IS, does the Attached bit count as a summary address or is it needed to advertise a summary address in IP reachability?[WAJ] The ABR should advertise a summary address. It’s the pre-condition to advertise the PUA/UPA message.
 
Ideally it would be good if the draft were updated to answer the above questions.[WAJ] We want to express again that the PUA solution is more thorough solution—covering more aspects than UPA solution, and is also earlier solution for this problem and should be the base for the future converge.There is also 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les

> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> (For some reason, email from you now goes into my Junk folder – delaying my 
> response. )
>  Acee –
>  Consider the simple topology:
>  A---B---C
>  A is the restarting router.
> C represents “the rest of the network” attached to B.
>  Router A goes down.
> Adjacency on B to A goes down.
> The LSPDB on C now has:
>  Router LSA B w no adjacency to A
> Router LSA A w adjacency to B (stale)
>  A comes up – adjacency between A and B forms.
> What happens next on C (and all the routers downstream) depends on order.
>  Case #1
> New Router LSA B w adjacency to A arrives.

With the change I proposed, Router B will not become adjacent to Router A 
without getting an updated version of Router A’s LSA that doesn’t include the 
link to Router B. 



> At this point, C believes there is two-way connectivity between A and B 
> because of the presence of the stale Router LSA A
> New Router LSA A w no adjacency to B arrives
> Now C has the up to date information
>  Case #2
> New Router LSA A w no adjacency to B arrives
> New Router LSA B w adjacency to A arrives
> C still sees no 2way connectivity between A and B
>  The reason you need to control the ordering is to prevent Case #1 from 
> occurring.
> Yes, this is a transient – LSPDB will eventually converge – but the duration 
> of “eventually’ depends on scale.
>  SA bit can be used to prevent Case #1 from ever occurring – or at least make 
> it very unlikely.

The change I proposed will prevent it as well. Router B will request Router A’s 
LSA and Router A will respond with the new version which doesn’t have the link 
to Router B. Router B will respond with the more-recent version (see this 
excerpt from RFC 2328 13.3):
  


(8) Else, the database copy is more recent. If the database copy
 has LS age equal to MaxAge and LS sequence number equal to
 MaxSequenceNumber, simply discard the received LSA without
 acknowledging it. (In this case, the LSA's LS sequence number is
 wrapping, and the MaxSequenceNumber LSA must be completely
 flushed before any new LSA instance can be introduced).
 Otherwise, as long as the database copy has not been sent in a
 Link State Update within the last MinLSArrival seconds, send the
 database copy back to the sending neighbor, encapsulated within
 a Link State Update Packet. The Link State Update Packet should
 be sent directly to the neighbor. In so doing, do not put the
 database copy of the LSA on the neighbor's link state
 retransmission list, and do not acknowledge the received (less 
recent)
 LSA instance.


Once Router A receives a more recent version and processed as described in 
section 13.4:


However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router
must take special action. The reception of such an LSA
indicates that there are LSAs in the routing domain that were
originated by the router before the last time it was restarted.
In most cases, the router must then advance the LSA's LS
sequence number one past the received LS sequence number, and
originate a new instance of the LSA.


Thanks,
Acee






>Les
>  From: Acee Lindem  
> Sent: Tuesday, March 28, 2023 10:02 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Liyan Gong ; Tony Przygienda 
> ; chen.mengxiao ; lsr 
> ; Weiqiang Cheng ; linchangwang 
> 
> Subject: Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>  Les, 
> 
> 
> On Mar 28, 2023, at 12:45, Les Ginsberg (ginsberg)  wrote:
>  Acee –
>  I will leave it to you and the other OSPF experts to decide what mechanism 
> you want to use in OSPF.
>  My only comment is that in the solution you proposed you did not account for 
> the synchronization needed between Steps 2, 3, 4.
> This is needed I think to prevent the neighbor LSA advertising the new 
> adjacency to the restarting router from being propagated before the updated 
> Router LSA (w no neighbors) from the restarting router is propagated.
> This is what avoids downstream routers from prematurely installing paths via 
> the restarting router.
>  Paths will not be installed until both routers advertise the link in their 
> Router-LSAs (due to the backlink check in the SPF computation). 
>  (b) Otherwise, W is a transit vertex (router or transit
> network).  Look up the vertex W's LSA (router-LSA or
> network-LSA) in Area A's link state database.  If the
> LSA does not exist, or its LS age is equal to MaxAge, or
> it does not have a link back to vertex V, examine the
> next link in V's LSA.[23]
>  
> The restarting router can delay advertising the link to account for any 
> required 

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[Les Ginsberg (ginsberg)]

Chris -


However, that is the missing piece, so it works if we also add a capability 
bit. If we have the capability bit you now know which routers are processing 
the container TLV and which aren't. That should be enough info to route 
correctly.

Using a container TLV *and* a capability bit is not a free lunch, but it should 
work to allow incremental deployment safely. If that's something we want as a 
WG.


No - this does not work.
Customer deploys some features. They expect all routers in the network to be 
able to correctly calculate topology and correctly forward for the features 
they support.
They do not deploy a feature and expect only a subset of the routers in the 
network that are configured to support the feature to correctly calculate paths.

There is no way to successfully support incremental deployment.

I already gave an example in my comments below:

> >> > [LES:] Consider the following simple example.
> >> >
> >> > Node A needs to send 10 sub-TLVs about a particular object –
> >> > requiring more than 255 bytes to be sent.
> >> >
> >> > Some nodes in the network do not support reception of more than 255
> >> > bytes/object. Consider two such nodes.
> >> >
> >> > Node B, based on the local configuration, needs to be able to receive
> >> > sub-TLVs 1,3,5,7,9 from A.
> >> >
> >> > Node C, based on local configuration, needs to be able to receive
> >> > sub-TLVs 2,4,6,8,10 from A.
> >> >
> >> >
> >> >
> >> > There is no way that A can advertise all 10 sub-TLVs in a way which
> >> > allows both B and C to correctly process the sub-TLVs they require.
> >> >

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Tuesday, March 28, 2023 9:52 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; Huaimo Chen
> ; draft-chen-lsr-isis-big-tlv.auth...@ietf.org;
> lsr@ietf.org
> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> 
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Chris -
> >
> > Please see inline - I'll try to conform to your request about ">>>" quoting 
> > -
> > but given that this style does not identify who made the comment, I have
> found
> > in the past that this style becomes very hard to follow after a couple of
> > replies.
> > Though perhaps that could be said of any style. 
> 
> Well in the ">>>" style my text that you were quoting would have been
> 
> "> like this"
> 
> and yours would not have anything preceding it.. like mine is here.
> 
> anyway, it's a losing battle against html I typically just load these email 
> into
> chrome when I need to read them..
> 
> >> -Original Message-
> >> From: Christian Hopps 
> >> Sent: Tuesday, March 28, 2023 7:27 AM
> >> To: Les Ginsberg (ginsberg) 
> >> Cc: Huaimo Chen ; draft-chen-lsr-isis-big-
> >> tlv.auth...@ietf.org; lsr@ietf.org
> >> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> >>
> >>
> >> Hi,
> >>
> >> So I agree that using this new container TLV along with old TLVs doesn't
> help.
> >>
> >
> >>>[LES:] Good - we agree.
> >
> >> However, it is worth nothing that if *only* the container TLV was used
> (i.e.,
> >> once a TLV became too large it would be removed and placed inside
> >> container TLVs) then it would actually represent a safer way to deploy this
> >> "multiple tlv" functionality.
> >>
> >> If the container only was used, then only routers that understood would
> be
> >> able to use *any* of the TLV data. This would actually solve the problem
> of
> >> "newly inserted legacy router brings everything back down" that using a
> >> required capability bit being set on all routers has.
> >>
> >>>[LES:] I don't agree - and here is why. Let's use the example of Neighbor
> TLVs.
> >>>With what you propose, when a router starts using the container TLV,
> those routers who don’t support/understand it would simply not be aware
> of the advertisement at all.
> >>>This would result in inconsistent routing calculations on different routers
> leading to loops/blackholes.
> >>>Hardly a benign impact.
> 
> You're right, not sure why I thought new routers would know that old routers
> weren't acting on the container TLV.
> 
> However, that is the missing piece, so it works if we also add a capability 
> bit.
> If we have the capability bit you now know which routers are processing the
> container TLV and which aren't. That should be enough info to route
> correctly.
> 
> >>>There is no free lunch here. No matter what encoding scheme you come
> up with, unless all routers in the network understand it, things are going to
> break.
> >
> 
> Using a container TLV *and* a capability bit is not a free lunch, but it 
> should
> work to allow incremental deployment safely. If that's something we want as
> a WG.
> 
> Thanks,
> Chris.
> [as wg-member]
> 
> >> This later issue with the capability bit is why no-one wanted to use a it,
> and
> >> why we currently have this very sub-optimal "solution" of "just do it and
> >> hope it works".
> >
> >>>[LES:] Folks (like me) who implemented 

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[Les Ginsberg (ginsberg)]

Chris -

Please see inline - I'll try to conform to your request about ">>>" quoting - 
but given that this style does not identify who made the comment, I have found 
in the past that this style becomes very hard to follow after a couple of 
replies.
Though perhaps that could be said of any style. 

> -Original Message-
> From: Christian Hopps 
> Sent: Tuesday, March 28, 2023 7:27 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Huaimo Chen ; draft-chen-lsr-isis-big-
> tlv.auth...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
> 
> 
> Hi,
> 
> So I agree that using this new container TLV along with old TLVs doesn't help.
> 

>>[LES:] Good - we agree.

> However, it is worth nothing that if *only* the container TLV was used (i.e.,
> once a TLV became too large it would be removed and placed inside
> container TLVs) then it would actually represent a safer way to deploy this
> "multiple tlv" functionality.
> 
> If the container only was used, then only routers that understood would be
> able to use *any* of the TLV data. This would actually solve the problem of
> "newly inserted legacy router brings everything back down" that using a
> required capability bit being set on all routers has.
>
>>[LES:] I don't agree - and here is why. Let's use the example of Neighbor 
>>TLVs.
>>With what you propose, when a router starts using the container TLV, those 
>>routers who don’t support/understand it would simply not be aware of the 
>>advertisement at all.
>>This would result in inconsistent routing calculations on different routers 
>>leading to loops/blackholes.
>>Hardly a benign impact.
>>
>>There is no free lunch here. No matter what encoding scheme you come up with, 
>>unless all routers in the network understand it, things are going to break.
 
> This later issue with the capability bit is why no-one wanted to use a it, and
> why we currently have this very sub-optimal "solution" of "just do it and
> hope it works".

>>[LES:] Folks (like me) who implemented MP for TLVs like Neighbor/Prefix were 
>>following established practice for the protocol i.e., there are multiple 
>>cases where this behavior is explicitly specified (please see MP draft for a 
>>list)
>>So it made sense to use the same mechanism for other TLVs.
>>We are not naïve - we understood very well that if not all routers in the 
>>network supported at least reception of MP TLVs that there would be 
>>deployment issues.
>>That is why I am working with enthusiasm on the MP draft.

   Les

> 
> Thanks,
> Chris.
> [as wg-member]
> 
> 
> P.S. the quoting style used in this thread is fabulously hard to comprehend in
> a text based email client.. What's wrong with good old ">>>" quoting style
> anyway?
> 
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Huaimo –
> >
> >
> >
> > Please see inline.
> >
> >
> >
> > From: Huaimo Chen 
> > Sent: Sunday, March 26, 2023 3:41 AM
> > To: Les Ginsberg (ginsberg) ; lsr@ietf.org;
> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org
> > Subject: Re: Comments on draft-chen-lsr-isis-big-tlv-00
> >
> >
> >
> > Hi Les,
> >
> >
> >
> > Thanks much for your comments.
> >
> > My responses are inline below with HC.
> >
> >
> >
> > Best Regards,
> >
> > Huaimo
> >
> >
> >
> > From: Les Ginsberg (ginsberg) 
> > Sent: Thursday, March 23, 2023 3:35 AM
> > To: lsr@ietf.org ;
> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org <
> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org>
> > Subject: Comments on draft-chen-lsr-isis-big-tlv-00
> >
> >
> >
> > Folks -
> >
> >
> >
> > This draft proposes a new way to handle advertisement of more than
> > 255 bytes of information about a given object.
> >
> > It defines a new "container TLV" to carry additional information
> > about an object beyond the (up to) 255 bytes of information
> > advertised in an existing TLV.
> >
> >
> >
> > The draft is defining a solution to a problem which has already been
> > addressed without requiring any protocol extensions.
> >
> > [HC]: It seems that a protocol includes a set of procedures. Would
> > you mind telling me which existing protocols can be used to resolve
> > the problem without requiring any protocol extensions?
> >
> >
> >
> > [LES:] Please read draft-pkaneria-lsr-multi-tlv-02 carefully.
> >
> > Section 1 documents that there are existing RFCs which explicitly
> > state that multiple TLVs for the same object are allowed to be sent.
> >
> > What the draft goes on to discuss is the use of the same mechanism
> > (sending multiple TLVs for the same object) in cases where existing
> > RFCs have not explicitly stated this behavior.
> >
> >
> >
> > It is also a fact that there are multiple implementations from
> > multiple vendors already shipping that utilize this mechanism for
> > TLVs such as Neighbor and Prefix reachability.
> >
> >
> >
> > The existing solution - discussed in https://datatracker.ietf.org/doc
> > /draft-pkaneria-lsr-multi-tlv/ has already been successfully
> > implemented and deployed by 

Re: [Lsr] Interdomain UPA & UP Flag

[Shraddha Hegde]

Most maintenance operations I have seen use ISIS overload with max metric 
advertise mechanism to
Switch the overlay services to another node. While this mechanism works fine 
for  MPLS environments that 
Leak the loopbacks across domains and in BGP-LU based environments, this 
mechanism is not
Available in deployments that use summarized prefixes for reachability.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Aijun Wang  
Sent: Tuesday, March 28, 2023 4:32 PM
To: Peter Psenak 
Cc: Shraddha Hegde ; Robert Raszuk ; 
lsr 
Subject: Re: [Lsr] Interdomain UPA & UP Flag

[External Email. Be cautious of content]


The following sentence should be:
> If it is planned, why the overlay service being switched over as scheduled?

If it is planned, why doesn’t the overlay service be switched over as scheduled?




Aijun Wang
China Telecom

> On Mar 28, 2023, at 19:53, Aijun Wang  wrote:
>
> There is no significant benefits to use the prefix unreachable announcement 
> mechanism to transfer the planned maintenance information.
>
> If it is planned, why the overlay service being switched over as scheduled?
>
> The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
> upon the accident network failures.
>
> Please pay more attentions to other aspects of such mechanism.
>
> Aijun Wang
> China Telecom
>
>>> On Mar 28, 2023, at 18:51, Peter Psenak 
>>>  wrote:
>>>
>>> On 28/03/2023 11:41, Aijun Wang wrote:
>>> There is already overload bit to accomplish the maintenance 
>>> purposes, Why do you guys repeat such work again?
>>
>> OL-bit is only propagated inside the area. We are solving 
>> inter-area/inter-domain routing convergence here.
>>
>> Peter
>>
>>> Aijun Wang
>>> China Telecom
> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>  wrote:

 Hi Robert,

> Second, if you say this is needed for BGP free deployments then I 
> question the merit on the basis that UPA is >ephemeral and expires 
> say in 120 sec which will not be enough for most planned 
> maintenance work. So if someone >insists to add UP Flag it should 
> be not just a bit but also a time or time delta from set UTC where 
> it is expected that >provided prefix will be down,

 That is a good point that there should be a max-time associated with 
 maintenance.

 I do not think that this needs to be signaled in IGP. It can be a local 
 configuration.

 Rgds

 Shraddha

 Juniper Business Use Only

 *From:* Lsr  *On Behalf Of *Robert Raszuk
 *Sent:* Monday, March 27, 2023 1:36 PM
 *To:* lsr 
 *Subject:* [Lsr] Interdomain UPA & UP Flag

 *[External Email. Be cautious of content]*

 Hi,

 I would like to get more clarification in respect to extending External 
 LSAs for UPA. Area summary use case is pretty clear - but in case of 
 redistribution (typical src of external LSAs) IMO we are going way too far 
 with this. Let's all keep in mind that this is a pulse designed to trigger 
 upper protocol switchover.

 Needless to say that would work only via one hop by design as 
 redistribution happens via RIB and by definition of UPA unreachable routes 
 are not being installed in RIB in the first place.

 On the apparently relative terms I do not see a need for the UP Flag. 
 First planned maintenance should be solved by BGP protocol and there are 
 already a number of tools in BGP allowing one to do it.

 Second, if you say this is needed for BGP free deployments then I 
 question the merit on the basis that UPA is ephemeral and expires 
 say in 120 sec which will not be enough for most planned 
 maintenance work. So if someone insists to add UP Flag it should be 
 not just a bit but also a time or time delta from set UTC where it 
 is expected that provided prefix will be down,

 Kind regards,

 R.

 ___
 Lsr mailing list
 Lsr@ietf.org
 https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
 sr__;!!NEt6yMaO-gk!FL0C5GIdGXqvoI4vgKh2djk4mgkPgInWxmoWOOpMb4mt7rBn
 QQ4e0rOGmZeNTkkGwpxGbwZ9jmR1cfW9YiEsw4uB$
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7406)

[Acee Lindem]

That explains it and it is actually the right thing to do from the perspective 
of the IETF document process. 

https://www.rfc-editor.org/materials/abbrev.expansion.txt

Note that LSP is not asterisked as being well known and “Label Switched Path” 
is the first alternative. It should always be expanded on first use. 

The Editorial Errata should be accepted. This is something we should watch for 
in documents specifying IS-IS. 

Thanks,
Acee

> On Mar 27, 2023, at 11:58 PM, Robert Raszuk  wrote:
> 
> Hi Barry,
> 
> Looks like RFC Editor expanded the "LSP" abbreviation as version -26 (last 
> before publication) says this: 
> 
> The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number. IS-
> IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given
> Flexible Algorithm (see Section 6).
> 
> 
> Rgs,
> R.
> 
> 
> On Mon, Mar 27, 2023 at 8:34 PM RFC Errata System  
> wrote:
> The following errata report has been submitted for RFC9350,
> "IGP Flexible Algorithm".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7406
> 
> --
> Type: Editorial
> Reported by: Barry Friedman 
> 
> Section: 5.1
> 
> Original Text
> -
> The IS-IS FAD sub-TLV MAY be advertised in a
> Label Switched Path (LSP) of any number.
> 
> Corrected Text
> --
> The IS-IS FAD sub-TLV MAY be advertised in a
> Link State PDU (LSP) of any number.
> 
> Notes
> -
> I assume LSP is meant to refer to the PDU carrying the FAD, not a Label 
> Switched Path.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9350 (draft-ietf-lsr-flex-algo-26)
> --
> Title   : IGP Flexible Algorithm
> Publication Date: February 2023
> Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, 
> A. Gulko
> Category: PROPOSED STANDARD
> Source  : Link State Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les, Liyan, 

With the change I suggested, a restarting router should be able to flood a 
Router-LSA without the link adjacencies before the corresponding neighbor comes 
full with the restarting. Additionally, if there are implementation-specific 
delays (such as SPF, route download, etc) that a restarting router wants to 
account for, it can simply delay advertising the Router-LSA link for an 
adjacency once it comes up. 

Just because we have this hello adjacency suppression hack in IS-IS doesn’t 
mean that we have to put it in OSPF. 


Thanks,
Acee 

> On Mar 28, 2023, at 01:46, Liyan Gong  wrote:
> 
>  
> Hi Les, Tony and Acee,
> 
> 
> 
> Appreciate your valuable suggestion. We will update the draft in the next 
> version as you suggested, including the title and detailed mechanism.
> 
> What Les has elabrated about the SA bit solution in the following email is 
> consistent with the idea. Thank you again for the detailed description.
> 
> Some additions are as follows:
> 
>   Yes, as Les says, this issue becomes more likely as the IGP scale increase 
> and can be seen in practice easily.
>   The key point is that, in OSPF, the LSA re-origination and neighbor full 
> are not in definite order. 
>   The larger the database, the slower the synchronization. This will delay 
> the lsa re-origination for restart router.
> 
>  
> 2.  Also because the LSA re-origination and neighbor full are not in definite 
> order,
> 
> Using the solution of requesting only router-lsa specially, The following 
> result I have mentioned becomes more likely:
> 
> Router B  has received the re-originated router lsa of router A, and 
> router A both get into the full state. Now A is reachable through spf tree 
> calculation.
> 
> As a result, the external route is also reachable, since the type 5 lsa 
> has not been re-originated.
>  
> To resolve this, the neighbor router must request all the lsas specially, 
> not only router-lsa. That is why I say this solution will cause more risk and 
> pressure.  
>  
> 3.  No obvious defect for the IS-IS SA bit has been seen in the practical 
> deployment. So, we think it is better to use the similar solution for OSPF.
> 
> 
>  
> 
> Best Regards,
> 
> Liyan
> 
> 
> 
> 
> 邮件原文
> 发件人："Les Ginsberg \\(ginsberg\\)"  >
> 收件人：Tony Przygienda  mailto:tonysi...@gmail.com>>
> 抄　送: Acee Lindem  mailto:acee.i...@gmail.com>>,Liyan 
> Gong   >,"chen.mengxiao"  >,lsr   >,Weiqiang Cheng  >,linchangwang  
> mailto:linchangwang.04...@h3c.com>>
> 发送时间：2023-03-28 10:44:41
> 主题：Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
> 
>
> Tony -
>  
> From: Tony Przygienda  
> Sent: Monday, March 27, 2023 5:11 PM
> To: Les Ginsberg (ginsberg) <>
> Cc: Acee Lindem ; Liyan Gong 
> ; chen.mengxiao ; lsr 
> ; Weiqiang Cheng ; linchangwang 
> 
> Subject: Re: [Lsr] 
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>  
> I didn't say "bigger", I said "random" ;-}
> [LES:] Ahhh…that makes all the difference. 
>  
> I tend to agree with SA bit solution though I don't grok how you can stop 
> flooding with that precisely. especially since you cannot rely on sequence of 
> hellos and DB sync packets arriving at the receiving node. And SA AFAIR 
> assumes LLC  or whatever while Acee's works on base spec ...
>  
> [LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with no 
> neighbor advertisement to the restarting router
> Step 2: Complete LSPDB sync – including Restarting router generating new 
> Router LSA w no neighbors
> Step 3: Delay to allow updated Router LSA  from Restarting router to be 
> flooded
> Step 4: Clear SA bit – neighboring routers can now advertise adjacency to the 
> Restarting router
> Step 5: Restarting router generates new Router LSA advertising neighbors
>  
> (To make this “extra reliable”, at Step 3 we can use your “random delay” 
> strategy.  )
>  
>Les
>  
> --- tony
>  
> On Tue, Mar 28, 2023 at 8:04AM Les Ginsberg (ginsberg)  > wrote:
> Tony –
>  
> It seems to me that the larger sequence # solution is less likely to work the 
> more you use it. 
> In other words, if I restart once a month, each time I need to pick an “even 
> bigger sequence #” to account for the starting point of the previous restart.
>  
> I know that with a 32 bit sequence #, we have decades of updates available, 
> but unless you save your most recent sequence # prior to restart you either 
> have to make a generous WAG  or risk the increasing likelihood that your WAG 
> won’t be big enough.
>  
> The SA bit logic is designed to allow the restarting router to control when 
> the neighbors can safely resume advertising the neighbor to the restarting 
> router.
> This has addressed problematic 

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[Christian Hopps]

Hi,

So I agree that using this new container TLV along with old TLVs doesn't help.

However, it is worth nothing that if *only* the container TLV was used (i.e., once a TLV 
became too large it would be removed and placed inside container TLVs) then it would 
actually represent a safer way to deploy this "multiple tlv" functionality.

If the container only was used, then only routers that understood would be able to use 
*any* of the TLV data. This would actually solve the problem of "newly inserted 
legacy router brings everything back down" that using a required capability bit 
being set on all routers has.

This later issue with the capability bit is why no-one wanted to use a it, and why we currently 
have this very sub-optimal "solution" of "just do it and hope it works".

Thanks,
Chris.
[as wg-member]


P.S. the quoting style used in this thread is fabulously hard to comprehend in a text based email 
client.. What's wrong with good old ">>>" quoting style anyway?


"Les Ginsberg (ginsberg)"  writes:


Huaimo –



Please see inline.



From: Huaimo Chen 
Sent: Sunday, March 26, 2023 3:41 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org;
draft-chen-lsr-isis-big-tlv.auth...@ietf.org
Subject: Re: Comments on draft-chen-lsr-isis-big-tlv-00



Hi Les,



Thanks much for your comments.

My responses are inline below with HC.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) 
Sent: Thursday, March 23, 2023 3:35 AM
To: lsr@ietf.org ;
draft-chen-lsr-isis-big-tlv.auth...@ietf.org <
draft-chen-lsr-isis-big-tlv.auth...@ietf.org>
Subject: Comments on draft-chen-lsr-isis-big-tlv-00



Folks -



This draft proposes a new way to handle advertisement of more than
255 bytes of information about a given object.

It defines a new "container TLV" to carry additional information
about an object beyond the (up to) 255 bytes of information
advertised in an existing TLV.



The draft is defining a solution to a problem which has already been
addressed without requiring any protocol extensions.

[HC]: It seems that a protocol includes a set of procedures. Would
you mind telling me which existing protocols can be used to resolve
the problem without requiring any protocol extensions?



[LES:] Please read draft-pkaneria-lsr-multi-tlv-02 carefully.

Section 1 documents that there are existing RFCs which explicitly
state that multiple TLVs for the same object are allowed to be sent.

What the draft goes on to discuss is the use of the same mechanism
(sending multiple TLVs for the same object) in cases where existing
RFCs have not explicitly stated this behavior.



It is also a fact that there are multiple implementations from
multiple vendors already shipping that utilize this mechanism for
TLVs such as Neighbor and Prefix reachability.



The existing solution - discussed in https://datatracker.ietf.org/doc
/draft-pkaneria-lsr-multi-tlv/ has already been successfully
implemented and deployed by multiple vendors.

[HC]: You are a co-author of this draft, called a first draft for
resolving the problem on big TLVs. This first draft contains some
protocol extensions. If there is a solution for the problem without
requiring any protocol extensions, then why do you as a co-author
work on the first draft with protocol extensions?



[LES:] There are no protocol extensions defined in
draft-pkaneria-lsr-multi-tlv-02 (please see the statement in the IANA
section). The draft has been written to clarify existing behavior and
to discuss best deployment practices in cases where not all
implementations support reception of multiple TLVs for a given
object.



The definition of a second solution to the problem is not needed -
and in fact further complicates both implementation and deployment.
Should the existing solution be used? Should the new solution be
used? What is the state of support by all nodes in the network for
each solution?

[HC]:  It seems better to merge the two drafts (i.e., the first draft
and the second draft defining container TLV) into one.



[LES:] This would the worst possible outcome.

It would define two mechanisms for sending more than 255 bytes of
information about an object.

This would require implementations to support two different
mechanisms for advertising the same information – also requiring the
ability to control which mechanism should be used in a given
deployment and even raising the possibility that both forms would
need to be sent in parallel. This adds unnecessary complexity to
implementations.



For operators deploying features+scale which require such support,
they would now have to identify not only whether all implementations
in their deployment support sending/receiving more than 255 bytes/
object, but also which form of advertisement is supported – further
complicating deployment considerations.



And since there are explicit statements requiring the current form of
advertisement to be used for some TLVs, behavior would potentially
differ on a per TLV basis.



The motivation 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

ok yes, I didn't think through the step 3 ...

thanks Les

-- tony

On Tue, Mar 28, 2023 at 11:44 AM Les Ginsberg (ginsberg) 
wrote:

> Tony -
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 5:11 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem ; Liyan Gong <
> gongli...@chinamobile.com>; chen.mengxiao ; lsr <
> lsr@ietf.org>; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> I didn't say "bigger", I said "random" ;-}
>
> *[LES:] Ahhh…that makes all the difference. ***
>
>
>
> I tend to agree with SA bit solution though I don't grok how you can stop
> flooding with that precisely. especially since you cannot rely on sequence
> of hellos and DB sync packets arriving at the receiving node. And SA AFAIR
> assumes LLC or whatever while Acee's works on base spec ...
>
>
>
> *[LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with
> no neighbor advertisement to the restarting router*
>
> *Step 2: Complete LSPDB sync – including Restarting router generating new
> Router LSA w no neighbors*
>
> *Step 3: Delay to allow updated Router LSA  from Restarting router to be
> flooded*
>
> *Step 4: Clear SA bit – neighboring routers can now advertise adjacency to
> the Restarting router*
>
> *Step 5: Restarting router generates new Router LSA advertising neighbors*
>
>
>
> *(To make this “extra reliable”, at Step 3 we can use your “random delay”
> strategy. **** )*
>
>
>
> *   Les*
>
>
>
> --- tony
>
>
>
> On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Tony –
>
>
>
> It seems to me that the larger sequence # solution is less likely to work
> the more you use it. 
>
> In other words, if I restart once a month, each time I need to pick an
> “even bigger sequence #” to account for the starting point of the previous
> restart.
>
>
>
> I know that with a 32 bit sequence #, we have decades of updates
> available, but unless you save your most recent sequence # prior to restart
> you either have to make a generous WAG or risk the increasing likelihood
> that your WAG won’t be big enough.
>
>
>
> The SA bit logic is designed to allow the restarting router to control
> when the neighbors can safely resume advertising the neighbor to the
> restarting router.
>
> This has addressed problematic cases seen even at low scale in IS-IS
> because IS-IS does not have the equivalent of Exchange state on adjacency
> bringup.
>
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue
> becomes more likely.
>
>
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address this aspect.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem 
> *Cc:* Liyan Gong ; chen.mengxiao <
> chen.mengx...@h3c.com>; Les Ginsberg (ginsberg) ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> thought about it. there are also other solutions to the problem (or rather
> to make it significantly less likely/shorter duration since perfect
> solution given we don't purge DB of an adjacenct router when we lose
> adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
> way that minimizes the problem (IMO simplest solution but only
> probabilistic).
>
>
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
>
>
> I see Acee's take as benign "over-compliance" to standard as we have it
> ;-) since the current wording does not say you MUST NOT do what he suggests
> ;-)
>
>
>
> -- tony
>
>
>
> On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
>
>
>
>
>
> Hi Acee,
>
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
>
>
> 1. First, About your doubts about the existence of the problem, I would
> like to check whether I have elaborated it clearly through the following
> email and the presentation.
>
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test 

Re: [Lsr] Interdomain UPA & UP Flag

[Aijun Wang]

The following sentence should be:
> If it is planned, why the overlay service being switched over as scheduled?

If it is planned, why doesn’t the overlay service be switched over as scheduled?




Aijun Wang
China Telecom

> On Mar 28, 2023, at 19:53, Aijun Wang  wrote:
> 
> There is no significant benefits to use the prefix unreachable announcement 
> mechanism to transfer the planned maintenance information.
> 
> If it is planned, why the overlay service being switched over as scheduled?
> 
> The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
> upon the accident network failures.
> 
> Please pay more attentions to other aspects of such mechanism.
> 
> Aijun Wang
> China Telecom
> 
>>> On Mar 28, 2023, at 18:51, Peter Psenak 
>>>  wrote:
>>> 
>>> On 28/03/2023 11:41, Aijun Wang wrote:
>>> There is already overload bit to accomplish the maintenance purposes,
>>> Why do you guys repeat such work again?
>> 
>> OL-bit is only propagated inside the area. We are solving 
>> inter-area/inter-domain routing convergence here.
>> 
>> Peter
>> 
>>> Aijun Wang
>>> China Telecom
> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>  wrote:
 
 Hi Robert,
 
> Second, if you say this is needed for BGP free deployments then I 
> question the merit on the basis that UPA is >ephemeral and expires say in 
> 120 sec which will not be enough for most planned maintenance work. So if 
> someone >insists to add UP Flag it should be not just a bit but also a 
> time or time delta from set UTC where it is expected that >provided 
> prefix will be down,
 
 That is a good point that there should be a max-time associated with 
 maintenance.
 
 I do not think that this needs to be signaled in IGP. It can be a local 
 configuration.
 
 Rgds
 
 Shraddha
 
 Juniper Business Use Only
 
 *From:* Lsr  *On Behalf Of *Robert Raszuk
 *Sent:* Monday, March 27, 2023 1:36 PM
 *To:* lsr 
 *Subject:* [Lsr] Interdomain UPA & UP Flag
 
 *[External Email. Be cautious of content]*
 
 Hi,
 
 I would like to get more clarification in respect to extending External 
 LSAs for UPA. Area summary use case is pretty clear - but in case of 
 redistribution (typical src of external LSAs) IMO we are going way too far 
 with this. Let's all keep in mind that this is a pulse designed to trigger 
 upper protocol switchover.
 
 Needless to say that would work only via one hop by design as 
 redistribution happens via RIB and by definition of UPA unreachable routes 
 are not being installed in RIB in the first place.
 
 On the apparently relative terms I do not see a need for the UP Flag. 
 First planned maintenance should be solved by BGP protocol and there are 
 already a number of tools in BGP allowing one to do it.
 
 Second, if you say this is needed for BGP free deployments then I question 
 the merit on the basis that UPA is ephemeral and expires say in 120 sec 
 which will not be enough for most planned maintenance work. So if someone 
 insists to add UP Flag it should be not just a bit but also a time or time 
 delta from set UTC where it is expected that provided prefix will be down,
 
 Kind regards,
 
 R.
 
 ___
 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

Re: [Lsr] Interdomain UPA & UP Flag

[Aijun Wang]

There is no significant benefits to use the prefix unreachable announcement 
mechanism to transfer the planned maintenance information.

If it is planned, why the overlay service being switched over as scheduled?

The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
upon the accident network failures.

Please pay more attentions to other aspects of such mechanism.

Aijun Wang
China Telecom

> On Mar 28, 2023, at 18:51, Peter Psenak  
> wrote:
> 
> On 28/03/2023 11:41, Aijun Wang wrote:
>> There is already overload bit to accomplish the maintenance purposes,
>> Why do you guys repeat such work again?
> 
> OL-bit is only propagated inside the area. We are solving 
> inter-area/inter-domain routing convergence here.
> 
> Peter
> 
>> Aijun Wang
>> China Telecom
 On Mar 28, 2023, at 18:00, Shraddha Hegde 
  wrote:
>>> 
>>> Hi Robert,
>>> 
>>> > Second, if you say this is needed for BGP free deployments then I 
>>> > question the merit on the basis that UPA is >ephemeral and expires say in 
>>> > 120 sec which will not be enough for most planned maintenance work. So if 
>>> > someone >insists to add UP Flag it should be not just a bit but also a 
>>> > time or time delta from set UTC where it is expected that >provided 
>>> > prefix will be down,
>>> 
>>> That is a good point that there should be a max-time associated with 
>>> maintenance.
>>> 
>>> I do not think that this needs to be signaled in IGP. It can be a local 
>>> configuration.
>>> 
>>> Rgds
>>> 
>>> Shraddha
>>> 
>>> Juniper Business Use Only
>>> 
>>> *From:* Lsr  *On Behalf Of *Robert Raszuk
>>> *Sent:* Monday, March 27, 2023 1:36 PM
>>> *To:* lsr 
>>> *Subject:* [Lsr] Interdomain UPA & UP Flag
>>> 
>>> *[External Email. Be cautious of content]*
>>> 
>>> Hi,
>>> 
>>> I would like to get more clarification in respect to extending External 
>>> LSAs for UPA. Area summary use case is pretty clear - but in case of 
>>> redistribution (typical src of external LSAs) IMO we are going way too far 
>>> with this. Let's all keep in mind that this is a pulse designed to trigger 
>>> upper protocol switchover.
>>> 
>>> Needless to say that would work only via one hop by design as 
>>> redistribution happens via RIB and by definition of UPA unreachable routes 
>>> are not being installed in RIB in the first place.
>>> 
>>> On the apparently relative terms I do not see a need for the UP Flag. First 
>>> planned maintenance should be solved by BGP protocol and there are already 
>>> a number of tools in BGP allowing one to do it.
>>> 
>>> Second, if you say this is needed for BGP free deployments then I question 
>>> the merit on the basis that UPA is ephemeral and expires say in 120 sec 
>>> which will not be enough for most planned maintenance work. So if someone 
>>> insists to add UP Flag it should be not just a bit but also a time or time 
>>> delta from set UTC where it is expected that provided prefix will be down,
>>> 
>>> Kind regards,
>>> 
>>> R.
>>> 
>>> ___
>>> 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

Re: [Lsr] Interdomain UPA & UP Flag

[Peter Psenak]

On 28/03/2023 11:41, Aijun Wang wrote:

There is already overload bit to accomplish the maintenance purposes,

Why do you guys repeat such work again?


OL-bit is only propagated inside the area. We are solving 
inter-area/inter-domain routing convergence here.


Peter




Aijun Wang
China Telecom

On Mar 28, 2023, at 18:00, Shraddha Hegde 
 wrote:


Hi Robert,

> Second, if you say this is needed for BGP free deployments then I 
question the merit on the basis that UPA is >ephemeral and expires say 
in 120 sec which will not be enough for most planned maintenance work. 
So if someone >insists to add UP Flag it should be not just a bit but 
also a time or time delta from set UTC where it is expected that 
>provided prefix will be down,


That is a good point that there should be a max-time associated with 
maintenance.


I do not think that this needs to be signaled in IGP. It can be a 
local configuration.


Rgds

Shraddha

Juniper Business Use Only

*From:* Lsr  *On Behalf Of *Robert Raszuk
*Sent:* Monday, March 27, 2023 1:36 PM
*To:* lsr 
*Subject:* [Lsr] Interdomain UPA & UP Flag

*[External Email. Be cautious of content]*

Hi,

I would like to get more clarification in respect to 
extending External LSAs for UPA. Area summary use case is pretty clear 
- but in case of redistribution (typical src of external LSAs) IMO we 
are going way too far with this. Let's all keep in mind that this is a 
pulse designed to trigger upper protocol switchover.


Needless to say that would work only via one hop by design as 
redistribution happens via RIB and by definition of UPA unreachable 
routes are not being installed in RIB in the first place.


On the apparently relative terms I do not see a need for the UP Flag. 
First planned maintenance should be solved by BGP protocol and there 
are already a number of tools in BGP allowing one to do it.


Second, if you say this is needed for BGP free deployments then I 
question the merit on the basis that UPA is ephemeral and expires say 
in 120 sec which will not be enough for most planned maintenance work. 
So if someone insists to add UP Flag it should be not just a bit but 
also a time or time delta from set UTC where it is expected that 
provided prefix will be down,


Kind regards,

R.

___
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

Re: [Lsr] Interdomain UPA & UP Flag

[Aijun Wang]

There is already overload bit to accomplish the maintenance purposes,

Why do you guys repeat such work again?


Aijun Wang
China Telecom

> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>  wrote:
> 
> 
> Hi Robert,
>  
> > Second, if you say this is needed for BGP free deployments then I question 
> > the merit on the basis that UPA is >ephemeral and expires say in 120 sec 
> > which will not be enough for most planned maintenance work. So if someone 
> > >insists to add UP Flag it should be not just a bit but also a time or time 
> > delta from set UTC where it is expected that >provided prefix will be down, 
>  
> That is a good point that there should be a max-time associated with 
> maintenance.
> I do not think that this needs to be signaled in IGP. It can be a local 
> configuration.
>  
> Rgds
> Shraddha
>  
>  
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Robert Raszuk
> Sent: Monday, March 27, 2023 1:36 PM
> To: lsr 
> Subject: [Lsr] Interdomain UPA & UP Flag
>  
> [External Email. Be cautious of content]
>  
> Hi,
>  
> I would like to get more clarification in respect to extending External LSAs 
> for UPA. Area summary use case is pretty clear - but in case of 
> redistribution (typical src of external LSAs) IMO we are going way too far 
> with this. Let's all keep in mind that this is a pulse designed to trigger 
> upper protocol switchover. 
>  
> Needless to say that would work only via one hop by design as redistribution 
> happens via RIB and by definition of UPA unreachable routes are not being 
> installed in RIB in the first place. 
>  
> On the apparently relative terms I do not see a need for the UP Flag. First 
> planned maintenance should be solved by BGP protocol and there are already a 
> number of tools in BGP allowing one to do it. 
>  
> Second, if you say this is needed for BGP free deployments then I question 
> the merit on the basis that UPA is ephemeral and expires say in 120 sec which 
> will not be enough for most planned maintenance work. So if someone insists 
> to add UP Flag it should be not just a bit but also a time or time delta from 
> set UTC where it is expected that provided prefix will be down, 
>  
> Kind regards,
> R.
> ___
> 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

Re: [Lsr] Interdomain UPA & UP Flag

[Shraddha Hegde]

Hi Robert,

> Second, if you say this is needed for BGP free deployments then I question 
> the merit on the basis that UPA is >ephemeral and expires say in 120 sec 
> which will not be enough for most planned maintenance work. So if someone 
> >insists to add UP Flag it should be not just a bit but also a time or time 
> delta from set UTC where it is expected that >provided prefix will be down,

That is a good point that there should be a max-time associated with 
maintenance.
I do not think that this needs to be signaled in IGP. It can be a local 
configuration.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr  On Behalf Of Robert Raszuk
Sent: Monday, March 27, 2023 1:36 PM
To: lsr 
Subject: [Lsr] Interdomain UPA & UP Flag

[External Email. Be cautious of content]

Hi,

I would like to get more clarification in respect to extending External LSAs 
for UPA. Area summary use case is pretty clear - but in case of redistribution 
(typical src of external LSAs) IMO we are going way too far with this. Let's 
all keep in mind that this is a pulse designed to trigger upper protocol 
switchover.

Needless to say that would work only via one hop by design as redistribution 
happens via RIB and by definition of UPA unreachable routes are not being 
installed in RIB in the first place.

On the apparently relative terms I do not see a need for the UP Flag. First 
planned maintenance should be solved by BGP protocol and there are already a 
number of tools in BGP allowing one to do it.

Second, if you say this is needed for BGP free deployments then I question the 
merit on the basis that UPA is ephemeral and expires say in 120 sec which will 
not be enough for most planned maintenance work. So if someone insists to add 
UP Flag it should be not just a bit but also a time or time delta from set UTC 
where it is expected that provided prefix will be down,

Kind regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA and planned/unplanned signalling

[Les Ginsberg (ginsberg)]

Shraddha -

Glad we have come to a common understanding.
One point inline.

> -Original Message-
> From: Shraddha Hegde 
> Sent: Monday, March 27, 2023 10:47 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: UPA and planned/unplanned signalling
> 
> Les,
> 
> Pls see inline..
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, March 28, 2023 11:02 AM
> To: Shraddha Hegde ; lsr@ietf.org
> Subject: RE: UPA and planned/unplanned signalling
> 
> [External Email. Be cautious of content]
> 
> 
> Shraddha -
> 
> Thanx for the response.
> 
> So the way you are proposing to use UPA on the receiving nodes is:
> 
> 1)For unplanned loss of reachability trigger BGP-PIC for immediate response
> 
> 2)For planned loss of reachability, don't trigger BGP-PIC - simply trigger a 
> best
> path calculation considering the high cost of reaching the node about to go
> into maintenance.
> You can "get away with doing this" because you assume that when you
> receive the UPA indicating planned maintenance that the node is still
> reachable i.e., maintenance hasn't actually started yet.
> 
> Do I understand you correctly?
>  That is correct.
> 
> This does help me to understand your motivation, but I am not fully
> appreciating the benefits.
> Whether you trigger BGP-PIC or not, you will have to do a new best path
> calculation. I don't see that not triggering BGP-PIC provides a benefit worth
> pursuing.
> But maybe we just will have to agree to disagree on that.
>  ok
> 
> If there is consensus to keep the two bits, I would suggest that the UP flag 
> be
> a modifier of the U flag i.e., the U flag is always set (planned or 
> unplanned),
> the UP flag is set in addition to the U flag when the trigger is planned
> maintenance. The UP flag would be ignored if sent without U flag set.
> This would provide a modest simplification for those implementations which
> don't care about the distinction - just look at the U flag.
> For those implementations that want to make the distinction you seem to
> favor, they would inspect both flags.
> 
> ??
>  The flags should be defined to mean one thing or the other which is
> how it is defined currently. I do not like the proposal  of defining the 
> meaning
> of the flags based on how one implementation wants to interpret them.
> It is quite surprising to me that looking at two different flags is presumably
> more complex for some implementations.
> However, I am not going to argue beyond this on this topic. I am fine with
> whatever co-authors decide on this.
> 
[LES2:] I don't want to overstate the importance of this modest change. But 
here is why I think it might be worth doing.

Whether the trigger is planned or unplanned, the UPA advertisement indicates 
the prefix is unreachable. U bit unambiguously signals that.
UP bit is really signaling additional context.
Suppose, in the future, someone comes up with yet another "context" associated 
with the  advertisement of unreachability. They might propose a "UX bit" (or 
whatever).
If we require only one bit to be set based on the "reason" for the UPA 
advertisement (U only, UP only, UX only), then existing implementations will 
have to be updated every time a new bit is defined.
If we say U bit is always set (because whatever the context the prefix still 
needs to be considered unreachable) and the additional bits provide additional 
information - then we can add additional bits in a backwards compatible manner.

   Les

>Les
> 
> 
> > -Original Message-
> > From: Shraddha Hegde 
> > Sent: Monday, March 27, 2023 9:25 PM
> > To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> > Subject: RE: UPA and planned/unplanned signalling
> >
> > Hi Les,
> >
> > Pls see inline for replies.
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Les Ginsberg (ginsberg) 
> > Sent: Tuesday, March 28, 2023 9:10 AM
> > To: Shraddha Hegde ; lsr@ietf.org
> > Subject: UPA and planned/unplanned signalling
> >
> > [External Email. Be cautious of content]
> >
> >
> > Shraddha -
> >
> > To follow up on our discussion over chat at the LSR meeting yesterday...
> >
> > At a remote ABR, if BGP had already been told about a planned node
> > maintenance event (by means that is outside the scope of the UPA
> > draft), then BGP would have moved traffic away from the node on which
> > the maintenance event is scheduled in advance of the arrival of the
> > UPA advertisement. In such a case the arrival of the UPA advertisement
> > would be of no significance. Since traffic has already moved away it
> > does not matter whether BGP processes the UPA or does not.
> >
> > If, however, BGP had NOT been told about planned maintenance in
> > advance, the arrival of the UPA should be treated in the same way
> > regardless of whether the trigger was a planned maintenance event or
> > not. The node associated with the address advertised in the UPA has
> > become unreachable