Re: [Lsr] Clarification on RFC 7794

[Shraddha Hegde]

Les,

Thank you for the clarification.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Thursday, November 18, 2021 8:36 PM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: Clarification on RFC 7794

[External Email. Be cautious of content]

Shraddha -

In the case you mention (redistribution from another protocol), the advertised 
router-id would be the ID of the originating router in the source protocol for 
redistribution.
In your example, this ID would come from OSPF. However, the term "router-id" 
means something different in OSPF. The corresponding identifier would come from 
the OSPF "Router Address TLV" defined in RFC 3630.

I am trying to be precise here. I wasn't certain when you used the term 
"redistributing router" whether you were referring to the source protocol or 
the destination protocol for redistribution.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Thursday, November 18, 2021 12:37 AM
To: lsr@ietf.org
Subject: [Lsr] Clarification on RFC 7794

WG,


I am looking for clarification on below text in RFC 7794 sec 2.2


"Note that the Router ID advertised is always the Router ID of the

   IS-IS instance that originated the advertisement.  This would be true

   even if the prefix had been learned from another protocol (i.e., with

   the X-flag set as defined in Section 
2.1)"


If a router is re-distributing a prefix from another ISIS instance it would put 
the source router-id of the
Originating router. If the prefix is being redistributed from another protocol 
(say OSPF) the source router-id of the
Prefix would be set to the router-id of the redistributing router. Is this the 
correct interpretation?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:


-Original Message-
From: tony1ath...@gmail.com  On Behalf Of Tony Li
Sent: Friday, November 19, 2021 9:08 AM
To: Aijun Wang 
Cc: Tony Przygienda ; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr@ietf.org; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


Hi Aijun,

At the risk of Tony confusion…
[WAJ] Will not confuse due to the different speaking and wording style. 


>> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the 
>> confusion here is that a presence of a /32 route is used as SSAP liveliness 
>> AFAIS and that's simply not what IGPs are here for if you consider their 
>> main job to be fastest possible convergence in network _reachability_ only 
>> and not signalling of service failures.
> 
> [WAJ] The problem is arose from the summary action of IGP, why let other 
> protocols solve it? 


There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
That’s not a property that it was meant to provide.  
[WAJ] The IGP advertises the summary reachability. The overlay service(BGP or 
tunnel) established based on this information. But when the endpoint of these 
overlay service is unreachable, the IGP still advertises the summary 
reachability. IGP should leak the actual information in such situation, doesn't 
insist that it can reach these failed address. 
And, as we have presented in the IETF meeting, the ABR Need Not advertise such 
information once there is prefix unreachable. The operator can configure the 
tracked/interested prefixes on the ABR.

We want scalability. That implies abstraction and that means that you can’t get 
a full link state database everywhere.
[WAJ] Yes. Current solution will not scarify the IGP scalability. As stated 
above, Not all link/prefix failures information will be delivered.

If you’re willing to forgo scalability, then do so.  Don’t use areas. Just have 
a flat routing domain.

Hole punching is going to put you in exactly the same place, sooner or later.  
You’re sacrificing scalability and adding another mechanism to do so.  Why 
bother?


>> Alternately resolving BGP over BGP as Robert suggests (if I read that 
>> correctly) and use RR to scale out the SSAP nhop availability is possible I 
>> think architecturally without garbage-canning IGPs as "network-wide fast 
>> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence 
>> ;-) but can be simpler hardware wise than trying to scale up BFD to large 
>> number of very fast sessions. 
> 
> 
> [WAJ] The operator doesn’t also want the network is filled with various queer 
> designs or solutions.


Then why are you proposing one? [BTW, I realize that you intended no offense, 
that’s probably NOT the best choice of words.]

There’s a reason that we’ve never gone down the path of hole punching before.  
And yes, it’s been discussed before, decades ago.
[WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
solutions will be needed more and more. I think it is different from the 
situation existing decades ago.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Gyan,

> On Nov 18, 2021, at 4:13 PM, Gyan Mishra  wrote:
> 
> The issue exists related to domain wide flooding to support seamless MPLS E2E 
> LSP which you end up with all host routes from all areas flooded domain wide 
> from Core and Agg layers.  So a solution to this domain wide flooding is area 
> summarization,  however in order to make summarization viable for convergence 
> we need a method to track the component prefixes when a failure occurs.  
> 
> So we have the two IGP based solutions but as this is an IGP issue, the issue 
> needs to be solved by the IGP.  I don’t think their is an easy way to solve 
> this in BGP.


It seems to me that having a full set of host routes, either positive or 
negative, is a really bad idea.  How about we not do that?

T


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

At the risk of Tony confusion…


>> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the 
>> confusion here is that a presence of a /32 route is used as SSAP liveliness 
>> AFAIS and that's simply not what IGPs are here for if you consider their 
>> main job to be fastest possible convergence in network _reachability_ only 
>> and not signalling of service failures.
> 
> [WAJ] The problem is arose from the summary action of IGP, why let other 
> protocols solve it? 


There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
That’s not a property that it was meant to provide.  

We want scalability. That implies abstraction and that means that you can’t get 
a full link state database everywhere.

If you’re willing to forgo scalability, then do so.  Don’t use areas. Just have 
a flat routing domain.

Hole punching is going to put you in exactly the same place, sooner or later.  
You’re sacrificing scalability and adding another mechanism to do so.  Why 
bother?


>> Alternately resolving BGP over BGP as Robert suggests (if I read that 
>> correctly) and use RR to scale out the SSAP nhop availability is possible I 
>> think architecturally without garbage-canning IGPs as "network-wide fast 
>> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence 
>> ;-) but can be simpler hardware wise than trying to scale up BFD to large 
>> number of very fast sessions. 
> 
> 
> [WAJ] The operator doesn’t also want the network is filled with various queer 
> designs or solutions.


Then why are you proposing one? [BTW, I realize that you intended no offense, 
that’s probably NOT the best choice of words.]

There’s a reason that we’ve never gone down the path of hole punching before.  
And yes, it’s been discussed before, decades ago.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Hi Tony

The issue exists related to domain wide flooding to support seamless MPLS
E2E LSP which you end up with all host routes from all areas flooded domain
wide from Core and Agg layers.  So a solution to this domain wide flooding
is area summarization,  however in order to make summarization viable for
convergence we need a method to track the component prefixes when a failure
occurs.

So we have the two IGP based solutions but as this is an IGP issue, the
issue needs to be solved by the IGP.  I don’t think their is an easy way to
solve this in BGP.

Kind Regards

Gyan
On Thu, Nov 18, 2021 at 6:22 PM Aijun Wang 
wrote:

> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
> On Nov 19, 2021, at 00:46, Tony Przygienda  wrote:
>
> 
> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS
> the confusion here is that a presence of a /32 route is used as SSAP
> liveliness AFAIS and that's simply not what IGPs are here for if you
> consider their main job to be fastest possible convergence in network
> _reachability_ only and not signalling of service failures.
>
>
> [WAJ] The problem is arose from the summary action of IGP, why let other
> protocols solve it?
>
> BGP is the overlay synchronizing SSAPs & scales marvelously @ that. Having
> BGP next-hop (which is basically equivalent to all services provided behind
> it) liveliness indicating the health of services behind it is the scalable
> solution IMO,
>
>
> [WAJ] Have discussed the BFD solutions several rounds on the list. Just
> for remind: BFD has the configuration overhead; and if PEs peer via the RR,
> BFD for BGP can’t solve.
>
> and not starting to try to teach IGP fragile signalling or PUAM (which BTW
> AFAIS will neither scale nor work on generic graphs due to lack of any
> consistent algebra I could detect in the draft and it is definitely nothing
> "like rift" as the preso seems to claim again) which will easily affect its
> main job.
>
> [WAJ] The PUAM solution meet any graph, not like the RIFT is suitable only
> some planned only topology. If you don’t agree, please give the example
> before making some unconvincing assertions.
> The reason that I mentioned RIFT is that you are familiar with it, just
> want you to understand the PUAM.
> Will the aggregate router advertise the detail reachability information to
> its leaves when the other aggregate router at the same sites can’t be
> reachable in RIFT?
> Even with the above similarities, we will try to avoid to mention RIFT
> later, because not all readers familiar with it.
>
> For signalling I see how putting it into a service instance is a somewhat
> palatable design choice and it's kind of like inventing "passive BFD" over
> flooding in my eyes ;-)
>
> [WAJ] Using service instance is rejected already. I think you have noticed
> Acee also mentioned this.
>
> And BTW, in topologically sorted graphs (CLOS being the ones of interest
> these days) with strict positive/negative disaggregation algebra with
> minimal blast radius on failures we can scale to (at least) 0.5M prefixes
> implementation wise IME and that should allow us really, really big IP
> fabrics with leaves holding nothing but defaults under normal conditions
> but it's still not a good idea to abuse that for SSAP synchronization AFAIS
> (and observe that to scale RIFT does NOT notify leaves of their vice-versa
> reachability, it simply prevents blackholing on aggregates and will produce
> an ICMP unreachable if there are no routes left to destination, if you run
> BFD on top of that as Tony suggests, this will of course give you the
> desired effect, for RR you'll run into the TCP session problem again but
> maybe you can BFD the RR session and then propagate that as Robert seems to
> suggest, the third-party next-hop raises its head again ;-).
>
> [WAJ] We are discussing the general solution, not the solution that
> specific only some limited topology.
>
>
> Alternately resolving BGP over BGP as Robert suggests (if I read that
> correctly) and use RR to scale out the SSAP nhop availability is possible I
> think architecturally without garbage-canning IGPs as "network-wide fast
> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence
> ;-) but can be simpler hardware wise than trying to scale up BFD to large
> number of very fast sessions.
>
>
> [WAJ] The operator doesn’t also want the network is filled with various
> queer designs or solutions.
>
>
> -- tony
>
>
>
> On Thu, Nov 18, 2021 at 5:06 PM Tony Li  wrote:
>
>>
>> Les,
>>
>> Why would we then punch holes in the summary for member routers?  Just
>> because we can?
>> *[LES:] No. We are doing it to improve convergence AND retain
>> scalability.*
>>
>>
>>
>> You are not improving convergence. You are propagating liveness.  The
>> fact that this relates to convergence in the overlay is irrelevant to the
>> IGP.
>>
>> You are not retaining scalability. You are damaging it. You are proposing
>> flooding a prefix per router that fails. If there is a

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 19, 2021, at 00:46, Tony Przygienda  wrote:
> 
> 
> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the 
> confusion here is that a presence of a /32 route is used as SSAP liveliness 
> AFAIS and that's simply not what IGPs are here for if you consider their main 
> job to be fastest possible convergence in network _reachability_ only and not 
> signalling of service failures.

[WAJ] The problem is arose from the summary action of IGP, why let other 
protocols solve it? 

> BGP is the overlay synchronizing SSAPs & scales marvelously @ that. Having 
> BGP next-hop (which is basically equivalent to all services provided behind 
> it) liveliness indicating the health of services behind it is the scalable 
> solution IMO,

[WAJ] Have discussed the BFD solutions several rounds on the list. Just for 
remind: BFD has the configuration overhead; and if PEs peer via the RR, BFD for 
BGP can’t solve.

> and not starting to try to teach IGP fragile signalling or PUAM (which BTW 
> AFAIS will neither scale nor work on generic graphs due to lack of any 
> consistent algebra I could detect in the draft and it is definitely nothing 
> "like rift" as the preso seems to claim again) which will easily affect its 
> main job.
[WAJ] The PUAM solution meet any graph, not like the RIFT is suitable only some 
planned only topology. If you don’t agree, please give the example before 
making some unconvincing assertions.
The reason that I mentioned RIFT is that you are familiar with it, just want 
you to understand the PUAM. 
Will the aggregate router advertise the detail reachability information to its 
leaves when the other aggregate router at the same sites can’t be reachable in 
RIFT?
Even with the above similarities, we will try to avoid to mention RIFT later, 
because not all readers familiar with it. 

> For signalling I see how putting it into a service instance is a somewhat 
> palatable design choice and it's kind of like inventing "passive BFD" over 
> flooding in my eyes ;-)
[WAJ] Using service instance is rejected already. I think you have noticed Acee 
also mentioned this.

> And BTW, in topologically sorted graphs (CLOS being the ones of interest 
> these days) with strict positive/negative disaggregation algebra with minimal 
> blast radius on failures we can scale to (at least) 0.5M prefixes 
> implementation wise IME and that should allow us really, really big IP 
> fabrics with leaves holding nothing but defaults under normal conditions but 
> it's still not a good idea to abuse that for SSAP synchronization AFAIS (and 
> observe that to scale RIFT does NOT notify leaves of their vice-versa 
> reachability, it simply prevents blackholing on aggregates and will produce 
> an ICMP unreachable if there are no routes left to destination, if you run 
> BFD on top of that as Tony suggests, this will of course give you the desired 
> effect, for RR you'll run into the TCP session problem again but maybe you 
> can BFD the RR session and then propagate that as Robert seems to suggest, 
> the third-party next-hop raises its head again ;-). 
[WAJ] We are discussing the general solution, not the solution that specific 
only some limited topology.

> 
> Alternately resolving BGP over BGP as Robert suggests (if I read that 
> correctly) and use RR to scale out the SSAP nhop availability is possible I 
> think architecturally without garbage-canning IGPs as "network-wide fast 
> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence 
> ;-) but can be simpler hardware wise than trying to scale up BFD to large 
> number of very fast sessions. 

[WAJ] The operator doesn’t also want the network is filled with various queer 
designs or solutions.

> 
> -- tony 
> 
> 
> 
>> On Thu, Nov 18, 2021 at 5:06 PM Tony Li  wrote:
>> 
>> Les,
>> 
>>> Why would we then punch holes in the summary for member routers?  Just 
>>> because we can?
>>> [LES:] No. We are doing it to improve convergence AND retain scalability.
>> 
>> 
>> You are not improving convergence. You are propagating liveness.  The fact 
>> that this relates to convergence in the overlay is irrelevant to the IGP.
>> 
>> You are not retaining scalability. You are damaging it. You are proposing 
>> flooding a prefix per router that fails. If there is a mass failure, that 
>> would result in flooding a large number of prefixes. The last thing you want 
>> when there is a mass failure is additional load, exacerbating the situation.
>> 
>> 
>>>  Should we corrupt the architecture just because we can?  There are other, 
>>> architecturally appropriate solutions available.  How about we just use 
>>> them?
>>>  
>>> [LES:] What are you proposing?
>> 
>> 
>> You are signaling the (lack of) liveness of a remote node. I propose that we 
>> instead use existing signaling mechanisms to do this. Multi-hop BFD seems 
>> like an obvious choice.
>> 
>> If you greatly dislike that for some reason, I woul

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Acee

We do have a lot of host routes in the hundreds of thousands across all
area but within an area at each level, core, aggregation,  we do also have
 close to hundreds of thousands of host routes as well that are flooded due
to the E2E seamless mpls hierarchy.

The flooding is much worse with seamless MPLS as all loopbacks for end to
end LSP have to be flooded domain wide.  But then you have the advantages
of seamless MPLS.

So for Verizon and any operator around the world using seamless MPLS could
take advantage of summarization and use of event notification or PUA for
convergence.  Also less memory and control plane overhead without the
flooding.

Also reduces the noise in the network from flapping churn as well.

Kind Regards

Gyan

On Thu, Nov 18, 2021 at 9:30 AM Acee Lindem (acee)  wrote:

> Hi Gyan,
>
>
>
> Are you saying you actually have hundreds of thousands of host routes in
> area routing domains? I guess this is across many areas? What is the use
> case (hopefully, in 40 words or less)?
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra 
> *Date: *Wednesday, November 17, 2021 at 9:35 PM
> *To: *Acee Lindem 
> *Cc: *Aijun Wang , Christian Hopps <
> cho...@chopps.org>, "Les Ginsberg (ginsberg)"  40cisco@dmarc.ietf.org>, "Les Ginsberg (ginsberg)" ,
> Tony Przygienda , "lsr@ietf.org" 
> *Subject: *Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> +1
>
>
>
> I completely agree.
>
>
>
> The failure is with the IGP being able to track the component prefixes
> that are part of a summary advertisement in large domains with hundreds of
> thousands of host routes chatter that without summarization could result in
> a meltdown.
>
>
>
> BGPs job is to carry the external prefixes and the underlay connected and
> egress PE LSP loopback FEC binding bgp next hop attribute is the job of the
> IGP to build the RIB/FIB and MPLS LFIB which is all based on the underlay
> IGP prefixes for hop by hop forwarding.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee)  wrote:
>
> The failure signaling pertains to a summary advertised in a normal routing
> instance and. If this problem is to be solved by the IGP, it definitely
> should be in the same instance as the summary itself. Hence, I second the
> motion to take the OSPF transport instance off the table for this
> application.
>
>
>
> Thanks,
> Acee
>
> P.S. You probably noticed that I’ve deferred comment on whether or not
> this should be solved in the IGP.
>
>
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Wednesday, November 17, 2021 at 8:09 PM
> *To: *Gyan Mishra , Aijun Wang <
> wangai...@tsinghua.org.cn>
> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
> lsr@ietf.org>, Christian Hopps , Tony Przygienda <
> tonysi...@gmail.com>, Acee Lindem 
> *Subject: *RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> I think the discussion about using a separate instance is a distraction
> and we shouldn’t be debating that right now.
>
>
>
> The legitimate question is whether folks see it as appropriate to have an
> IGP based solution for the problem. How to do it using the IGP is only a
> meaningful question if we are considering using the IGP at all.
>
>
>
> In that context…it is clear that it is a legitimate use of the IGP to
> advertise summary addresses.
>
> It is also a legitimate use of the IGPs to advertise all the individual
> prefixes covered by a summary if the network operator chooses not to
> summarize.
>
> It therefore seems to me to quite legitimate for the IGP to advertise both
> a summary and changes to the reachability of individual destinations
> covered by the summary. This is still a type of prefix reachability
> advertisement.
>
>
>
> It would help me if the folks who think this is NOT a legitimate use of an
> IGP could explain why in the context of the above.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, November 17, 2021 4:32 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ;
> lsr@ietf.org; Christian Hopps ; Tony Przygienda <
> tonysi...@gmail.com>; Acee Lindem (acee) 
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> With MT separate control plane common data plane or Multi Instance
> separate control plane and separate data plane.
>
>
>
> In both transport instance styles peeling the event notification into a
> separate instance or topology how do this discrete transport instance or
> topology interact with the main instance or topology.
>
>
>
> The answer is it can’t.
>
>
>
> As Aijun as well as Peter have discussed the problem this is an inherent
> issue with use of summarization and these are two solutions to solbe this
> real world issue to make summarization viable for operators.
>
>
>
> Gyan
>
> Verizon Inc
>
>
>
> On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang 
> wrote:
>
> Hi, Christian:
>

[Lsr] I-D Action: draft-ietf-lsr-ospf-transport-instance-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Transport Instance Extensions
Authors : Acee Lindem
  Yingzhen Qu
  Abhay Roy
  Sina Mirtorabi
Filename: draft-ietf-lsr-ospf-transport-instance-01.txt
Pages   : 14
Date: 2021-11-18

Abstract:
   OSPFv2 and OSPFv3 include a reliable flooding mechanism to
   disseminate routing topology and Traffic Engineering (TE) information
   within a routing domain.  Given the effectiveness of these
   mechanisms, it is convenient to envision using the same mechanism for
   dissemination of other types of information within the domain.
   However, burdening OSPF with this additional information will impact
   intra-domain routing convergence and possibly jeopardize the
   stability of the OSPF routing domain.  This document presents
   mechanism to relegate this ancillary information to a separate OSPF
   instance and minimize the impact.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-transport-instance-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-transport-instance-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Tony,

On 18/11/2021 17:38, Tony Li wrote:

Les,

You are not retaining scalability. You are damaging it. You are 
proposing flooding a prefix per router that fails. If there is a mass 
failure, that would result in flooding a large number of prefixes. The 
last thing you want when there is a mass failure is additional load, 
exacerbating the situation.
*/[LES2:] It is reasonable to limit the rate of pulses sent. Peter has 
already indicated in an earlier reply that we will address that in a 
future version of the event-notification draft.  So, good point – and 
we are in agreement regarding mass failure./*



The fact that you have to limit the result is a pretty clear indication 
that this is not architecturally appropriate.


using that logic, IGPs would not be suitable for half of the things they 
are used for. We have areas to limit the flood radius, we have 
summarization to limit the prefix scope, we have SPF backoff to limit 
the SPFs, etc. The presence of these does not indicate that we use IGPs 
inappropriately.





You are signaling the (lack of) liveness of a remote node. I propose 
that we instead use existing signaling mechanisms to do this. 
Multi-hop BFD seems like an obvious choice.

*/[LES2:] Conceptually this works. But I don’t think it scales./*



How so? Doesn’t this correspond 1:1 with overlay BGP sessions?


PEs typically only peer with RRs, not between themselves.




If you greatly dislike that for some reason, I would suggest that we 
create a proxy liveness service, advertised by the ABR. This would 
allow correspondents to register for notifications. The ABR could 
signal these unicast when it determines that the specific targets are 
unreachable.

*/[LES:] This would be a significant effort to provide such a service./*
*/Granted, implementation of “pulse” is also a significant effort – so 
I am not objecting to your idea simply based on that. I am just 
pointing out that what you propose does not currently exist – so if 
you are serious about this alternative you need to provide the details./*



Fear of hard work does not make it the IGP’s problem.


nor should it prevent us to consider IGPs, especially when the 
alternative would likely lead to the definition of the new protocol 
(e.g. liveness service, advertised by the ABR).


thanks,
Peter



I am not the one with the issue. Those with the issue should propose the 
details. At most, the IGP should carry a capability for this service.


Tony




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

Re: [Lsr] Issues with master/slave terminology in OSPF

[tom petch]

From: Lsr  on behalf of Mike Fox 
Sent: 16 November 2021 20:53

Many companies in the industry including mine are undergoing initiatives
to replace offensive terminology in IT.  One of the targeted terms is
master/slave, which is used in OSPF database exchange and the terms appear
in various documentation and displays for our OSPF routing daemon.  I'm
still waiting on guidance on whether or not  industry-standard terms get a
pass, but it's not looking good.  Has anyone else encountered this issue
and if so how have you handled it? If I'm going to need to change to
terminology that does not match the RFC I'd like to be consistent with
what others are doing.



Mike

The IESG statement triggered a lengthy discussion on the main IETF list 
23jul2020 which was shut down by the IETF Chair as unhelpful 11aug20.   (There 
are references to the 'terminology' list but I do not know what went on there).

The use of master and slave got quite an airing and the sense I got was that 
the referenced documents, of which there are several from several sources, do 
not address the issue of a controlling and controlled entity as is common in 
electronics, protocols and engineering in general.  There might have been some 
progress in the past year but I see no evidence thereof.

Equally, my sense was that there was no consensus in support of taking 
draft-knodel as a way forward, political pressure perhaps, but not IETF 
consensus.

Tom Petch


Thank you,
Mike

IBM Enterprise Network Solutions Architecture & Design

Research Triangle Park, NC  USA

___
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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi les,

*[LES2:] It is reasonable to limit the rate of pulses sent. Peter has
> already indicated in an earlier reply that we will address that in a future
> version of the event-notification draft.  So, good point – and we are in
> agreement regarding mass failure.*
>

In respect to the anti-choke timer out of curiosity, what is your
definition of "mass failure" ?

100 pulses in a second ? 1000 in a second ? Least Common Denominator the
weakest IGP node in the domain could handle ?

Is this to be rate limit with queuing the rest to just smooth the peak in
time or drop the rest ?

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the
confusion here is that a presence of a /32 route is used as SSAP liveliness
AFAIS and that's simply not what IGPs are here for if you consider their
main job to be fastest possible convergence in network _reachability_ only
and not signalling of service failures. BGP is the overlay synchronizing
SSAPs & scales marvelously @ that. Having BGP next-hop (which is basically
equivalent to all services provided behind it) liveliness indicating the
health of services behind it is the scalable solution IMO, and not starting
to try to teach IGP fragile signalling or PUAM (which BTW AFAIS will
neither scale nor work on generic graphs due to lack of any consistent
algebra I could detect in the draft and it is definitely nothing "like
rift" as the preso seems to claim again) which will easily affect its main
job. For signalling I see how putting it into a service instance is a
somewhat palatable design choice and it's kind of like inventing "passive
BFD" over flooding in my eyes ;-) And BTW, in topologically sorted graphs
(CLOS being the ones of interest these days) with strict positive/negative
disaggregation algebra with minimal blast radius on failures we can scale
to (at least) 0.5M prefixes implementation wise IME and that should allow
us really, really big IP fabrics with leaves holding nothing but defaults
under normal conditions but it's still not a good idea to abuse that for
SSAP synchronization AFAIS (and observe that to scale RIFT does NOT notify
leaves of their vice-versa reachability, it simply prevents blackholing on
aggregates and will produce an ICMP unreachable if there are no routes left
to destination, if you run BFD on top of that as Tony suggests, this will
of course give you the desired effect, for RR you'll run into the TCP
session problem again but maybe you can BFD the RR session and then
propagate that as Robert seems to suggest, the third-party next-hop raises
its head again ;-).

Alternately resolving BGP over BGP as Robert suggests (if I read that
correctly) and use RR to scale out the SSAP nhop availability is possible I
think architecturally without garbage-canning IGPs as "network-wide fast
broadcast mechanism" ... I doubt it will do "couple millisecs" convergence
;-) but can be simpler hardware wise than trying to scale up BFD to large
number of very fast sessions.

-- tony



On Thu, Nov 18, 2021 at 5:06 PM Tony Li  wrote:

>
> Les,
>
> Why would we then punch holes in the summary for member routers?  Just
> because we can?
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
> You are not improving convergence. You are propagating liveness.  The fact
> that this relates to convergence in the overlay is irrelevant to the IGP.
>
> You are not retaining scalability. You are damaging it. You are proposing
> flooding a prefix per router that fails. If there is a mass failure, that
> would result in flooding a large number of prefixes. The last thing you
> want when there is a mass failure is additional load, exacerbating the
> situation.
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
> *[LES:] What are you proposing?*
>
>
>
> You are signaling the (lack of) liveness of a remote node. I propose that
> we instead use existing signaling mechanisms to do this. Multi-hop BFD
> seems like an obvious choice.
>
> If you greatly dislike that for some reason, I would suggest that we
> create a proxy liveness service, advertised by the ABR. This would allow
> correspondents to register for notifications. The ABR could signal these
> unicast when it determines that the specific targets are unreachable.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi Tony,

> How so? Doesn’t this correspond 1:1 with overlay BGP sessions?

Not at all.

BGP is never full mesh across multiple areas. RR hops are used. BFD does
not have concept of RRs last time I looked at it :)

Kind regards,
R.





On Thu, Nov 18, 2021 at 5:38 PM Tony Li  wrote:

> Les,
>
> You are not retaining scalability. You are damaging it. You are proposing
> flooding a prefix per router that fails. If there is a mass failure, that
> would result in flooding a large number of prefixes. The last thing you
> want when there is a mass failure is additional load, exacerbating the
> situation.
>
> *[LES2:] It is reasonable to limit the rate of pulses sent. Peter has
> already indicated in an earlier reply that we will address that in a future
> version of the event-notification draft.  So, good point – and we are in
> agreement regarding mass failure.*
>
>
>
> The fact that you have to limit the result is a pretty clear indication
> that this is not architecturally appropriate.
>
>
> You are signaling the (lack of) liveness of a remote node. I propose that
> we instead use existing signaling mechanisms to do this. Multi-hop BFD
> seems like an obvious choice.
> *[LES2:] Conceptually this works. But I don’t think it scales.*
>
>
>
> How so? Doesn’t this correspond 1:1 with overlay BGP sessions?
>
>
> If you greatly dislike that for some reason, I would suggest that we
> create a proxy liveness service, advertised by the ABR. This would allow
> correspondents to register for notifications. The ABR could signal these
> unicast when it determines that the specific targets are unreachable.
>
> *[LES:] This would be a significant effort to provide such a service.*
> *Granted, implementation of “pulse” is also a significant effort – so I am
> not objecting to your idea simply based on that. I am just pointing out
> that what you propose does not currently exist – so if you are serious
> about this alternative you need to provide the details.*
>
>
>
> Fear of hard work does not make it the IGP’s problem.
>
> I am not the one with the issue. Those with the issue should propose the
> details. At most, the IGP should carry a capability for this service.
>
> Tony
>
>
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Les,

> You are not retaining scalability. You are damaging it. You are proposing 
> flooding a prefix per router that fails. If there is a mass failure, that 
> would result in flooding a large number of prefixes. The last thing you want 
> when there is a mass failure is additional load, exacerbating the situation.
>  
> [LES2:] It is reasonable to limit the rate of pulses sent. Peter has already 
> indicated in an earlier reply that we will address that in a future version 
> of the event-notification draft.  So, good point – and we are in agreement 
> regarding mass failure.


The fact that you have to limit the result is a pretty clear indication that 
this is not architecturally appropriate.


> You are signaling the (lack of) liveness of a remote node. I propose that we 
> instead use existing signaling mechanisms to do this. Multi-hop BFD seems 
> like an obvious choice.
> [LES2:] Conceptually this works. But I don’t think it scales.


How so? Doesn’t this correspond 1:1 with overlay BGP sessions?


> If you greatly dislike that for some reason, I would suggest that we create a 
> proxy liveness service, advertised by the ABR. This would allow 
> correspondents to register for notifications. The ABR could signal these 
> unicast when it determines that the specific targets are unreachable.
>  
> [LES:] This would be a significant effort to provide such a service.
> Granted, implementation of “pulse” is also a significant effort – so I am not 
> objecting to your idea simply based on that. I am just pointing out that what 
> you propose does not currently exist – so if you are serious about this 
> alternative you need to provide the details.


Fear of hard work does not make it the IGP’s problem. 

I am not the one with the issue. Those with the issue should propose the 
details. At most, the IGP should carry a capability for this service.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Les Ginsberg (ginsberg)]

Tony -

From: Lsr  On Behalf Of Tony Li
Sent: Thursday, November 18, 2021 8:07 AM
To: Les Ginsberg (ginsberg) 
Cc: Gyan Mishra ; Christian Hopps ; 
Aijun Wang ; lsr@ietf.org; Acee Lindem (acee) 
; Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


Les,

Why would we then punch holes in the summary for member routers?  Just because 
we can?
[LES:] No. We are doing it to improve convergence AND retain scalability.


You are not improving convergence. You are propagating liveness.  The fact that 
this relates to convergence in the overlay is irrelevant to the IGP.

You are not retaining scalability. You are damaging it. You are proposing 
flooding a prefix per router that fails. If there is a mass failure, that would 
result in flooding a large number of prefixes. The last thing you want when 
there is a mass failure is additional load, exacerbating the situation.

[LES2:] It is reasonable to limit the rate of pulses sent. Peter has already 
indicated in an earlier reply that we will address that in a future version of 
the event-notification draft.  So, good point - and we are in agreement 
regarding mass failure.

 Should we corrupt the architecture just because we can?  There are other, 
architecturally appropriate solutions available.  How about we just use them?

[LES:] What are you proposing?


You are signaling the (lack of) liveness of a remote node. I propose that we 
instead use existing signaling mechanisms to do this. Multi-hop BFD seems like 
an obvious choice.
[LES2:] Conceptually this works. But I don’t think it scales.

If you greatly dislike that for some reason, I would suggest that we create a 
proxy liveness service, advertised by the ABR. This would allow correspondents 
to register for notifications. The ABR could signal these unicast when it 
determines that the specific targets are unreachable.

[LES:] This would be a significant effort to provide such a service.
Granted, implementation of “pulse” is also a significant effort - so I am not 
objecting to your idea simply based on that. I am just pointing out that what 
you propose does not currently exist - so if you are serious about this 
alternative you need to provide the details.

   Les

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> If you want to address this problem with BGP keep alive timers, that’s
certainly an alternative as well.

Nope that is not what I previously described in this thread.

BGP uses recursion. So you can propage next hops in BGP and recurse your
service route next hops over those with simple config knob to only consider
/32 or /128 routes as next hops.

Local detection of node going down can be done with BFD or LOS:  TOR to RR
or Compute to TOR or ... BGP propagation via few RRs will be in
milliseconds. Then you can also apply constrain equal to service route
constrains to limit the blast to only those targets which need that info.
Not sure how to do such limiting in proposed IGP solutions.

Thx,
R.



On Thu, Nov 18, 2021 at 5:16 PM Tony Li  wrote:

>
> Robert,
>
> Why would we need to deploy a full mesh of BFD or introduce a new proxy
> liveness service if BGP can do all what is needed here with just a few
> lines of additional cfg on existing and deployed operating systems ?
>
>
>
> If you want to address this problem with BGP keep alive timers, that’s
> certainly an alternative as well.
>
> Additional configuration is not a good metric on architectural complexity
> and fragility.  The worst ‘features’ can be enabled with a single line. :)
>
>
> In respect to using BFD here - let's start with basic question - who would
> be the producer to install those host routes into RIB ? Note in the
> discussed scenario there are not there today - only summary is there.
>
>
>
> Why do you assume that BFD would produce a route? I would instead suggest
> that the overlay BGP would register with BFD for notifications about a
> remote.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Robert,

> Why would we need to deploy a full mesh of BFD or introduce a new proxy 
> liveness service if BGP can do all what is needed here with just a few lines 
> of additional cfg on existing and deployed operating systems ? 


If you want to address this problem with BGP keep alive timers, that’s 
certainly an alternative as well.

Additional configuration is not a good metric on architectural complexity and 
fragility.  The worst ‘features’ can be enabled with a single line. :)


> In respect to using BFD here - let's start with basic question - who would be 
> the producer to install those host routes into RIB ? Note in the discussed 
> scenario there are not there today - only summary is there. 


Why do you assume that BFD would produce a route? I would instead suggest that 
the overlay BGP would register with BFD for notifications about a remote.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Tony,

Why would we need to deploy a full mesh of BFD or introduce a new proxy
liveness service if BGP can do all what is needed here with just a few
lines of additional cfg on existing and deployed operating systems ?

In respect to using BFD here - let's start with basic question - who would
be the producer to install those host routes into RIB ? Note in the
discussed scenario there are not there today - only summary is there.

Thx,
R.

On Thu, Nov 18, 2021 at 5:06 PM Tony Li  wrote:

>
> Les,
>
> Why would we then punch holes in the summary for member routers?  Just
> because we can?
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
> You are not improving convergence. You are propagating liveness.  The fact
> that this relates to convergence in the overlay is irrelevant to the IGP.
>
> You are not retaining scalability. You are damaging it. You are proposing
> flooding a prefix per router that fails. If there is a mass failure, that
> would result in flooding a large number of prefixes. The last thing you
> want when there is a mass failure is additional load, exacerbating the
> situation.
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
> *[LES:] What are you proposing?*
>
>
>
> You are signaling the (lack of) liveness of a remote node. I propose that
> we instead use existing signaling mechanisms to do this. Multi-hop BFD
> seems like an obvious choice.
>
> If you greatly dislike that for some reason, I would suggest that we
> create a proxy liveness service, advertised by the ABR. This would allow
> correspondents to register for notifications. The ABR could signal these
> unicast when it determines that the specific targets are unreachable.
>
> Tony
>
>
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Les,

> Why would we then punch holes in the summary for member routers?  Just 
> because we can?
> [LES:] No. We are doing it to improve convergence AND retain scalability.


You are not improving convergence. You are propagating liveness.  The fact that 
this relates to convergence in the overlay is irrelevant to the IGP.

You are not retaining scalability. You are damaging it. You are proposing 
flooding a prefix per router that fails. If there is a mass failure, that would 
result in flooding a large number of prefixes. The last thing you want when 
there is a mass failure is additional load, exacerbating the situation.


>  Should we corrupt the architecture just because we can?  There are other, 
> architecturally appropriate solutions available.  How about we just use them?
>  
> [LES:] What are you proposing?


You are signaling the (lack of) liveness of a remote node. I propose that we 
instead use existing signaling mechanisms to do this. Multi-hop BFD seems like 
an obvious choice.

If you greatly dislike that for some reason, I would suggest that we create a 
proxy liveness service, advertised by the ABR. This would allow correspondents 
to register for notifications. The ABR could signal these unicast when it 
determines that the specific targets are unreachable.

Tony


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

Re: [Lsr] Clarification on RFC 7794

[Les Ginsberg (ginsberg)]

Shraddha -

In the case you mention (redistribution from another protocol), the advertised 
router-id would be the ID of the originating router in the source protocol for 
redistribution.
In your example, this ID would come from OSPF. However, the term "router-id" 
means something different in OSPF. The corresponding identifier would come from 
the OSPF "Router Address TLV" defined in RFC 3630.

I am trying to be precise here. I wasn't certain when you used the term 
"redistributing router" whether you were referring to the source protocol or 
the destination protocol for redistribution.

   Les


From: Lsr  On Behalf Of Shraddha Hegde
Sent: Thursday, November 18, 2021 12:37 AM
To: lsr@ietf.org
Subject: [Lsr] Clarification on RFC 7794

WG,


I am looking for clarification on below text in RFC 7794 sec 2.2


"Note that the Router ID advertised is always the Router ID of the

   IS-IS instance that originated the advertisement.  This would be true

   even if the prefix had been learned from another protocol (i.e., with

   the X-flag set as defined in Section 
2.1)"


If a router is re-distributing a prefix from another ISIS instance it would put 
the source router-id of the
Originating router. If the prefix is being redistributed from another protocol 
(say OSPF) the source router-id of the
Prefix would be set to the router-id of the redistributing router. Is this the 
correct interpretation?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

On 18/11/2021 15:54, Robert Raszuk wrote:


Btw even with eBGP between TOR and compute I have just checked and I see 
cases of some deployments not setting next hop self on TORs hence 
original next hop set by compute is used in service routes.


Link between TOR and compute is passive IGP link/subnet.


that's what I thought would be the case. And in such case the IGP 
solution would work for you.



Peter




Thx,
R.

On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang > wrote:


Hi, Robert:

If you use iBGP in your mentioned scenario, how to propagate the
reachability of  BGP nexthop? I think it is impossible to use again
BGP itself. Then depend only BGP can’t solve your problem.

If the underlying using IGP to propagate such reachability
information, we have mechanism to control for which covered prefix
to send the notification when they become unreachable. It is not
randomly suppressed.


Aijun Wang
China Telecom


On Nov 18, 2021, at 21:27, Robert Raszuk mailto:rob...@raszuk.net>> wrote:


In such cases I would rather consider implementing pulse to be
less then host route.

Suppressing them randomly may lead to even bigger disappointment
of unreachability propagation hence delaying connectivity
restoration to a backup path.

Many thx,
R.

On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak mailto:ppse...@cisco.com>> wrote:

Robert,

On 18/11/2021 13:42, Robert Raszuk wrote:
>     [WAJ] In the scenarios that you mentioned, BGP nexthop
reachability
>     is derived from the directed interface, there is no
summary action
>     done by the router. Is that true?
>
>
> Not necessarily - TORs do not always do eBGP to compute and
set next hop
> self. There can be IBGP session there and therefor next hop
is not
> changed all the way to the remote compute. But the point was
that today
> BGP is involved already in reachability and service
distribution.
>
> And while current IGP proposals can propagate this too the
point is
> about scalability when it comes to signalling of such
massive failures
> in the IGP. The amount of IGP traffic and processing in
those moments
> may be significant.

we can certainly address such case by not allowing thousands
of pulses
to be generated in case half of the universe falls apart. That
seems
obvious and easy to implement.

thanks,
Peter

>
> And yes I agree this is not really a "hole punching" ...
that was just a
> description shortcut I used.
>
> Thx,
> R.



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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Btw even with eBGP between TOR and compute I have just checked and I see
cases of some deployments not setting next hop self on TORs hence original
next hop set by compute is used in service routes.

Link between TOR and compute is passive IGP link/subnet.

Thx,
R.

On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> If you use iBGP in your mentioned scenario, how to propagate the
> reachability of  BGP nexthop? I think it is impossible to use again BGP
> itself. Then depend only BGP can’t solve your problem.
>
> If the underlying using IGP to propagate such reachability information, we
> have mechanism to control for which covered prefix to send the notification
> when they become unreachable. It is not randomly suppressed.
>
>
> Aijun Wang
> China Telecom
>
> On Nov 18, 2021, at 21:27, Robert Raszuk  wrote:
>
> 
>
> In such cases I would rather consider implementing pulse to be less then
> host route.
>
> Suppressing them randomly may lead to even bigger disappointment of
> unreachability propagation hence delaying connectivity restoration to a
> backup path.
>
> Many thx,
> R.
>
> On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak  wrote:
>
>> Robert,
>>
>> On 18/11/2021 13:42, Robert Raszuk wrote:
>> > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
>> > is derived from the directed interface, there is no summary action
>> > done by the router. Is that true?
>> >
>> >
>> > Not necessarily - TORs do not always do eBGP to compute and set next
>> hop
>> > self. There can be IBGP session there and therefor next hop is not
>> > changed all the way to the remote compute. But the point was that today
>> > BGP is involved already in reachability and service distribution.
>> >
>> > And while current IGP proposals can propagate this too the point is
>> > about scalability when it comes to signalling of such massive failures
>> > in the IGP. The amount of IGP traffic and processing in those moments
>> > may be significant.
>>
>> we can certainly address such case by not allowing thousands of pulses
>> to be generated in case half of the universe falls apart. That seems
>> obvious and easy to implement.
>>
>> thanks,
>> Peter
>>
>> >
>> > And yes I agree this is not really a "hole punching" ... that was just
>> a
>> > description shortcut I used.
>> >
>> > Thx,
>> > R.
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Christian:

Aijun Wang
China Telecom

> On Nov 18, 2021, at 18:13, Christian Hopps  wrote:
> 
> 
> 
>> On Nov 17, 2021, at 6:09 PM, Aijun Wang  wrote:
>> 
>> Hi, Christian:
>> 
>> Would you like to describe how to solve the problem via using the transport 
>> instance? The detail interaction process within the node and the deployment  
>> overhead analysis?
> 
> 
> As A WG member:
> 
> When I said in the meeting "As a WG member, I agree" I was specifically 
> referring to the gist of his statement which was that this wasn't worth 
> putting into the main protocol. I'm unconvinced (again as a WG member) that 
> there's a problem worth trying to solve here -- at least one that rises above 
> the "should we add something to the the protocol" level.

[WAJ] Should it be “whoever makes a mistake, who corrects”?

> 
> That said, the main point that I believe I was making here was that his 
> comment was a good one to make during the adoption call (or preferably before 
> we got to this point), so that discussion around it could happen on the list.

[WAJ] Yeah, I think it has happened. There is no other better option to solve 
such problem now. If exists, please describe it.

> 
> Thanks,
> Chris.
> 
>> If there is no such information, it is doubt whether your judgment is 
>> correct or not, it is also unconvincing. Welcome also Tony gives the 
>> explanation before making the assertions, as we done for PUAM solution.
> 
> 
> 
> 
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Nov 17, 2021, at 22:59, Christian Hopps  wrote:
>>> 
>>> 
>>> 
 On Nov 16, 2021, at 10:36 PM, Aijun Wang  wrote:
 
 Hi, 
 
 The followings are the responses for the comments on PUAM 
 draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
 
 Les:  The comment I want to make, I think the discussion on the
list highlighted the fact that there's an open question,
independent of whether we use the prefix unreachable
draft or the Event Notification draft, as to whether this
problem should be solved by the IGP or whether it should be
solved by BGP, or in some other way. And I think the logical
way to proceed on this is to get the consensus of the working
group as to whether an IGP solution is desired first, then
after we reach consensus on that, then we can start talking
about which approach is the better approach. Which one
should be adopted?
 【WAJ】The problem is occurred due to the summary action by the ABR router 
 in IGP, it should be solved by IGP itself.
 As discussed earlier on the list, the possible use case is not limited to 
 BGP fast convergence.
 Based on the above considerations, it is not appropriated solved via BGP. 
 
 Chris H:  Chair hat on. You've been asking for adoption for a while.
The event notification draft is new. I agree with Les that
in a perfect world that would be the case, but asking for
adoption is one way to answer the question. It may be not
the perfect way to answer that question, but it is one way.
I agree without my chair hat on, I'm not sure we need this,
but it's not for me to say by fiat. Acee did put something
out on the list to try to engage people again. And I don't
think a lot got said.
 【WAJ】we have several round discussions for this topic but there is always 
 no conclusion at the end. 
 Can the expert that reluctant to accept the new idea to give some 
 specific questions/problems for the current solution?
Or else it is not helpful for the solve of the existing problem.
 Initiate the adoption call maybe the best way to let the experts 
 express their opinions? 
 We would like to hear the specific and detail comments for the current 
 solutions, not just general comments.
 
 Acee: I didn't see much support other than from the authors. I
saw one non-author support on the event notification. 
 【WAJ】Does anyone not agree what we analyze/summarize at the presentation 
 material for the two solutions? 
 (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
  the 5th slide)
 
 Chris:Everyone has a right to ask for an adoption. Everyone has a
right to say we shouldn't adopt this and there are the
reasons. We've let people to express opinions, without
seeing a lot of negative opinions it's hard not to just grant
the adoption call.
 【WAJ】I agree.
 
 Tony P:   I think this is all making a trash can out of the IGP. One
possible solution is to ban or encouraged maybe everyone with
these kind of suggestions to go towards the service instance
stuff or whatever w

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Acee Lindem (acee)]

Hi Gyan,

Are you saying you actually have hundreds of thousands of host routes in area 
routing domains? I guess this is across many areas? What is the use case 
(hopefully, in 40 words or less)?

Thanks,
Acee

From: Gyan Mishra 
Date: Wednesday, November 17, 2021 at 9:35 PM
To: Acee Lindem 
Cc: Aijun Wang , Christian Hopps 
, "Les Ginsberg (ginsberg)" 
, "Les Ginsberg (ginsberg)" 
, Tony Przygienda , "lsr@ietf.org" 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


+1

I completely agree.

The failure is with the IGP being able to track the component prefixes that are 
part of a summary advertisement in large domains with hundreds of thousands of 
host routes chatter that without summarization could result in a meltdown.

BGPs job is to carry the external prefixes and the underlay connected and 
egress PE LSP loopback FEC binding bgp next hop attribute is the job of the IGP 
to build the RIB/FIB and MPLS LFIB which is all based on the underlay IGP 
prefixes for hop by hop forwarding.

Kind Regards

Gyan

On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
The failure signaling pertains to a summary advertised in a normal routing 
instance and. If this problem is to be solved by the IGP, it definitely should 
be in the same instance as the summary itself. Hence, I second the motion to 
take the OSPF transport instance off the table for this application.

Thanks,
Acee
P.S. You probably noticed that I’ve deferred comment on whether or not this 
should be solved in the IGP.


From: "Les Ginsberg (ginsberg)" 
mailto:40cisco@dmarc.ietf.org>>
Date: Wednesday, November 17, 2021 at 8:09 PM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>, Aijun 
Wang mailto:wangai...@tsinghua.org.cn>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>, Tony Przygienda 
mailto:tonysi...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

I think the discussion about using a separate instance is a distraction and we 
shouldn’t be debating that right now.

The legitimate question is whether folks see it as appropriate to have an IGP 
based solution for the problem. How to do it using the IGP is only a meaningful 
question if we are considering using the IGP at all.

In that context…it is clear that it is a legitimate use of the IGP to advertise 
summary addresses.
It is also a legitimate use of the IGPs to advertise all the individual 
prefixes covered by a summary if the network operator chooses not to summarize.
It therefore seems to me to quite legitimate for the IGP to advertise both a 
summary and changes to the reachability of individual destinations covered by 
the summary. This is still a type of prefix reachability advertisement.

It would help me if the folks who think this is NOT a legitimate use of an IGP 
could explain why in the context of the above.

Thanx.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Gyan 
Mishra
Sent: Wednesday, November 17, 2021 4:32 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; Christian Hopps 
mailto:cho...@chopps.org>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


With MT separate control plane common data plane or Multi Instance separate 
control plane and separate data plane.

In both transport instance styles peeling the event notification into a 
separate instance or topology how do this discrete transport instance or 
topology interact with the main instance or topology.

The answer is it can’t.

As Aijun as well as Peter have discussed the problem this is an inherent issue 
with use of summarization and these are two solutions to solbe this real world 
issue to make summarization viable for operators.

Gyan
Verizon Inc

On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Christian:

Would you like to describe how to solve the problem via using the transport 
instance? The detail interaction process within the node and the deployment  
overhead analysis?
If there is no such information, it is doubt whether your judgment is correct 
or not, it is also unconvincing. Welcome also Tony gives the explanation before 
making the assertions, as we done for PUAM solution.


Aijun Wang
China Telecom

> On Nov 17, 2021, at 22:59, Christian Hopps 
> mailto:cho...@chopps.org>> wrote:
>
>
>
>> On Nov 16, 2021, at 10:36 PM, Aijun Wang 
>> mailto:wangai...@tsinghua.org.cn>> wrote:
>>
>> Hi,
>>
>> The followings are the responses for the comments on PUAM 
>> draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-u

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Next hops are part of the IGP summary when advertising outside of the area.
Within area those are host routes usually or smaller subnets (/24s for
TOR-Compute LANs).

Thx,
R.

On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> If you use iBGP in your mentioned scenario, how to propagate the
> reachability of  BGP nexthop? I think it is impossible to use again BGP
> itself. Then depend only BGP can’t solve your problem.
>
> If the underlying using IGP to propagate such reachability information, we
> have mechanism to control for which covered prefix to send the notification
> when they become unreachable. It is not randomly suppressed.
>
>
> Aijun Wang
> China Telecom
>
> On Nov 18, 2021, at 21:27, Robert Raszuk  wrote:
>
> 
>
> In such cases I would rather consider implementing pulse to be less then
> host route.
>
> Suppressing them randomly may lead to even bigger disappointment of
> unreachability propagation hence delaying connectivity restoration to a
> backup path.
>
> Many thx,
> R.
>
> On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak  wrote:
>
>> Robert,
>>
>> On 18/11/2021 13:42, Robert Raszuk wrote:
>> > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
>> > is derived from the directed interface, there is no summary action
>> > done by the router. Is that true?
>> >
>> >
>> > Not necessarily - TORs do not always do eBGP to compute and set next
>> hop
>> > self. There can be IBGP session there and therefor next hop is not
>> > changed all the way to the remote compute. But the point was that today
>> > BGP is involved already in reachability and service distribution.
>> >
>> > And while current IGP proposals can propagate this too the point is
>> > about scalability when it comes to signalling of such massive failures
>> > in the IGP. The amount of IGP traffic and processing in those moments
>> > may be significant.
>>
>> we can certainly address such case by not allowing thousands of pulses
>> to be generated in case half of the universe falls apart. That seems
>> obvious and easy to implement.
>>
>> thanks,
>> Peter
>>
>> >
>> > And yes I agree this is not really a "hole punching" ... that was just
>> a
>> > description shortcut I used.
>> >
>> > Thx,
>> > R.
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

If you use iBGP in your mentioned scenario, how to propagate the reachability 
of  BGP nexthop? I think it is impossible to use again BGP itself. Then depend 
only BGP can’t solve your problem.

If the underlying using IGP to propagate such reachability information, we have 
mechanism to control for which covered prefix to send the notification when 
they become unreachable. It is not randomly suppressed.


Aijun Wang
China Telecom

> On Nov 18, 2021, at 21:27, Robert Raszuk  wrote:
> 
> 
> 
> In such cases I would rather consider implementing pulse to be less then host 
> route. 
> 
> Suppressing them randomly may lead to even bigger disappointment of 
> unreachability propagation hence delaying connectivity restoration to a 
> backup path. 
> 
> Many thx,
> R.
> 
>> On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak  wrote:
>> Robert,
>> 
>> On 18/11/2021 13:42, Robert Raszuk wrote:
>> > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
>> > is derived from the directed interface, there is no summary action
>> > done by the router. Is that true?
>> > 
>> > 
>> > Not necessarily - TORs do not always do eBGP to compute and set next hop 
>> > self. There can be IBGP session there and therefor next hop is not 
>> > changed all the way to the remote compute. But the point was that today 
>> > BGP is involved already in reachability and service distribution.
>> > 
>> > And while current IGP proposals can propagate this too the point is 
>> > about scalability when it comes to signalling of such massive failures 
>> > in the IGP. The amount of IGP traffic and processing in those moments 
>> > may be significant.
>> 
>> we can certainly address such case by not allowing thousands of pulses 
>> to be generated in case half of the universe falls apart. That seems 
>> obvious and easy to implement.
>> 
>> thanks,
>> Peter
>> 
>> > 
>> > And yes I agree this is not really a "hole punching" ... that was just a 
>> > description shortcut I used.
>> > 
>> > Thx,
>> > R.
>> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

In such cases I would rather consider implementing pulse to be less then
host route.

Suppressing them randomly may lead to even bigger disappointment of
unreachability propagation hence delaying connectivity restoration to a
backup path.

Many thx,
R.

On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak  wrote:

> Robert,
>
> On 18/11/2021 13:42, Robert Raszuk wrote:
> > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
> > is derived from the directed interface, there is no summary action
> > done by the router. Is that true?
> >
> >
> > Not necessarily - TORs do not always do eBGP to compute and set next hop
> > self. There can be IBGP session there and therefor next hop is not
> > changed all the way to the remote compute. But the point was that today
> > BGP is involved already in reachability and service distribution.
> >
> > And while current IGP proposals can propagate this too the point is
> > about scalability when it comes to signalling of such massive failures
> > in the IGP. The amount of IGP traffic and processing in those moments
> > may be significant.
>
> we can certainly address such case by not allowing thousands of pulses
> to be generated in case half of the universe falls apart. That seems
> obvious and easy to implement.
>
> thanks,
> Peter
>
> >
> > And yes I agree this is not really a "hole punching" ... that was just a
> > description shortcut I used.
> >
> > Thx,
> > R.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Robert,

On 18/11/2021 13:42, Robert Raszuk wrote:

[WAJ] In the scenarios that you mentioned, BGP nexthop reachability
is derived from the directed interface, there is no summary action
done by the router. Is that true?


Not necessarily - TORs do not always do eBGP to compute and set next hop 
self. There can be IBGP session there and therefor next hop is not 
changed all the way to the remote compute. But the point was that today 
BGP is involved already in reachability and service distribution.


And while current IGP proposals can propagate this too the point is 
about scalability when it comes to signalling of such massive failures 
in the IGP. The amount of IGP traffic and processing in those moments 
may be significant.


we can certainly address such case by not allowing thousands of pulses 
to be generated in case half of the universe falls apart. That seems 
obvious and easy to implement.


thanks,
Peter



And yes I agree this is not really a "hole punching" ... that was just a 
description shortcut I used.


Thx,
R.


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

>
> [WAJ] In the scenarios that you mentioned, BGP nexthop reachability is
> derived from the directed interface, there is no summary action done by the
> router. Is that true?
>

Not necessarily - TORs do not always do eBGP to compute and set next hop
self. There can be IBGP session there and therefor next hop is not changed
all the way to the remote compute. But the point was that today BGP is
involved already in reachability and service distribution.

And while current IGP proposals can propagate this too the point is about
scalability when it comes to signalling of such massive failures in the
IGP. The amount of IGP traffic and processing in those moments may be
significant.

And yes I agree this is not really a "hole punching" ... that was just a
description shortcut I used.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

I want to add one comments based on Peter’s comments.

Aijun Wang
China Telecom

> On Nov 18, 2021, at 19:30, Peter Psenak  
> wrote:
> 
> Robert,
> 
>> On 18/11/2021 11:33, Robert Raszuk wrote:
>> Les, All,
>> One thing to keep in mind in this entire discussion is the reality of 
>> compute nodes becoming L3 routing nodes in many new architectures. The 
>> protocol which is used between TORs and such compute nodes is almost always 
>> BGP. That means that no matter what we do in the IGP we will not avoid using 
>> BGP for propagating both service reachability and next hop reachability of 
>> such service.

[WAJ] In the scenarios that you mentioned, BGP nexthop reachability is derived 
from the directed interface, there is no summary action done by the router. Is 
that true?

>> In all discussions so far I have not seen an indication that the proposed 
>> solution covers the above case. If I have compute's next hops covered by the 
>> summary and that compute goes down would I signal it in the IGP across 
>> areas/levels ?
> 
> If the IGP is aware of the reachability of the compute's next hop and it 
> summarizes such reachability between areas/domains, it can for sure notify 
> about such  compute's next hop becoming unreachable.
> 
>> On the other hand TORs do not go down that much. So if we are to proceed 
>> with IGP based signalling of lost reachability I highly encourage to 
>> consider real problems and keep in mind scalability aspects in the event 
>> someone would like to punch holes in the summaries also based on specific 
>> compute nodes going down. Yes often BFD compute to TOR runs BFD so can be a 
>> trigger.
> 
> first, we are not necessarily punching holes. At least with the event 
> notification it does not leave any state, so "punching a hole in summary" is 
> not the correct description of it. Second, remote PE going down may not be a 
> very frequent event, but it is a possible event and there are existing 
> solution that covers it. We are trying to extend the coverage for the case 
> where network is using the summarization.
> 
> 
> thanks,
> Peter
> 
>> We as networking people often put a wall between network and compute ... 
>> well in reality there is no wall there any more**. So what we build must 
>> consider service end to end not only traditional routers to be really 
>> effective.
>> Thx,
>> R.
>> PS.  ** I came to know a few week's back that some well known financial 
>> company is joining network and compute teams into one.
>> On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg) 
>> mailto:40cisco@dmarc.ietf.org>> 
>> wrote:
>>Tony –
>>__ __
>>Inline.
>>__ __
>>*From:* Tony Li >> *On Behalf Of *Tony Li
>>*Sent:* Wednesday, November 17, 2021 5:24 PM
>>*To:* Les Ginsberg (ginsberg) >>
>>*Cc:* Gyan Mishra >>; Aijun Wang
>>mailto:wangai...@tsinghua.org.cn>>;
>>lsr@ietf.org ; Christian Hopps
>>mailto:cho...@chopps.org>>; Acee Lindem (acee)
>>mailto:a...@cisco.com>>; Tony Przygienda
>>mailto:tonysi...@gmail.com>>
>>*Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE:
>>IETF 112 LSR Meeting Minutes
>>__ __
>>__ __
>>Les,
>>__ __
>>That’s easy.  The summary covers all addresses of all of the nodes
>>(hosts and routers) in the area. It also may cover addresses within
>>the summary that are not currently assigned. This is intentional
>>since by advertising a summary, we gain scalability. The summary
>>provides aggregated reachability throughout the network.
>>__ __
>>Reachability and path selection is the responsibility of the IGP,
>>not liveness.
>>__ __
>>Should we not advertise a summary because a single address in the
>>summary is not assigned?  No, it is up to correspondents to
>>determine if the address is populated.
>>__ __
>>Should we punch holes in our summary for unassigned addresses?  No,
>>that would kill scalability.
>>__ __
>>Should we punch holes in our summary for host failures?  That would
>>kill scalability too and drag the IGP out of its role. 
>>__ __
>>Why would we then punch holes in the summary for member routers? Just 
>> because we can? 
>>*/[LES:] No. We are doing it to improve convergence AND retain
>>scalability./*
>>*/__ __/*
>>  Should we corrupt the architecture just because we can?  There are
>>other, architecturally appropriate solutions available.  How about
>>we just use them?
>>__ __
>>*/[LES:] What are you proposing?/*
>>*/__ __/*
>>*/   Les/*
>>__ __
>>Regards,
>>Tony
>>__ __
>>__ __
>>__ __
>>On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg)
>>>>

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Robert,

On 18/11/2021 11:33, Robert Raszuk wrote:

Les, All,

One thing to keep in mind in this entire discussion is the reality of 
compute nodes becoming L3 routing nodes in many new architectures. The 
protocol which is used between TORs and such compute nodes is almost 
always BGP. That means that no matter what we do in the IGP we will not 
avoid using BGP for propagating both service reachability and next hop 
reachability of such service.


In all discussions so far I have not seen an indication that the 
proposed solution covers the above case. If I have compute's next hops 
covered by the summary and that compute goes down would I signal it in 
the IGP across areas/levels ?


If the IGP is aware of the reachability of the compute's next hop and it 
summarizes such reachability between areas/domains, it can for sure 
notify about such  compute's next hop becoming unreachable.




On the other hand TORs do not go down that much. So if we are to proceed 
with IGP based signalling of lost reachability I highly encourage to 
consider real problems and keep in mind scalability aspects in the event 
someone would like to punch holes in the summaries also based on 
specific compute nodes going down. Yes often BFD compute to TOR runs BFD 
so can be a trigger.


first, we are not necessarily punching holes. At least with the event 
notification it does not leave any state, so "punching a hole in 
summary" is not the correct description of it. Second, remote PE going 
down may not be a very frequent event, but it is a possible event and 
there are existing solution that covers it. We are trying to extend the 
coverage for the case where network is using the summarization.



thanks,
Peter



We as networking people often put a wall between network and compute ... 
well in reality there is no wall there any more**. So what we build must 
consider service end to end not only traditional routers to be really 
effective.


Thx,
R.

PS.  ** I came to know a few week's back that some well known financial 
company is joining network and compute teams into one.



On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg) 
> wrote:


Tony –

__ __

Inline.

__ __

*From:* Tony Li mailto:tony1ath...@gmail.com>> *On Behalf Of *Tony Li
*Sent:* Wednesday, November 17, 2021 5:24 PM
*To:* Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
*Cc:* Gyan Mishra mailto:hayabusa...@gmail.com>>; Aijun Wang
mailto:wangai...@tsinghua.org.cn>>;
lsr@ietf.org ; Christian Hopps
mailto:cho...@chopps.org>>; Acee Lindem (acee)
mailto:a...@cisco.com>>; Tony Przygienda
mailto:tonysi...@gmail.com>>
*Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE:
IETF 112 LSR Meeting Minutes

__ __

__ __

Les,

__ __

That’s easy.  The summary covers all addresses of all of the nodes
(hosts and routers) in the area. It also may cover addresses within
the summary that are not currently assigned. This is intentional
since by advertising a summary, we gain scalability. The summary
provides aggregated reachability throughout the network.

__ __

Reachability and path selection is the responsibility of the IGP,
not liveness.

__ __

Should we not advertise a summary because a single address in the
summary is not assigned?  No, it is up to correspondents to
determine if the address is populated.

__ __

Should we punch holes in our summary for unassigned addresses?  No,
that would kill scalability.

__ __

Should we punch holes in our summary for host failures?  That would
kill scalability too and drag the IGP out of its role. 

__ __

Why would we then punch holes in the summary for member routers? 
Just because we can? 


*/[LES:] No. We are doing it to improve convergence AND retain
scalability./*

*/__ __/*

  Should we corrupt the architecture just because we can?  There are
other, architecturally appropriate solutions available.  How about
we just use them?

__ __

*/[LES:] What are you proposing?/*

*/__ __/*

*/   Les/*

__ __

Regards,

Tony

__ __

__ __

__ __

On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg)
mailto:ginsberg=40cisco@dmarc.ietf.org>> wrote:

__ __

I think the discussion about using a separate instance is a
distraction and we shouldn’t be debating that right now.



The legitimate question is whether folks see it as appropriate
to have an IGP based solution for the problem. How to do it
using the IGP is only a meaningful question if we are
considering using the IGP at all.



In that context…it is clear that it is a legitimate use of the
IGP to advertise s

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Les, All,

One thing to keep in mind in this entire discussion is the reality of
compute nodes becoming L3 routing nodes in many new architectures. The
protocol which is used between TORs and such compute nodes is almost always
BGP. That means that no matter what we do in the IGP we will not avoid
using BGP for propagating both service reachability and next hop
reachability of such service.

In all discussions so far I have not seen an indication that the proposed
solution covers the above case. If I have compute's next hops covered by
the summary and that compute goes down would I signal it in the IGP
across areas/levels ?

On the other hand TORs do not go down that much. So if we are to proceed
with IGP based signalling of lost reachability I highly encourage to
consider real problems and keep in mind scalability aspects in the event
someone would like to punch holes in the summaries also based on specific
compute nodes going down. Yes often BFD compute to TOR runs BFD so can be a
trigger.

We as networking people often put a wall between network and compute ...
well in reality there is no wall there any more**. So what we build must
consider service end to end not only traditional routers to be really
effective.

Thx,
R.

PS.  ** I came to know a few week's back that some well known financial
company is joining network and compute teams into one.


On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg)  wrote:

> Tony –
>
>
>
> Inline.
>
>
>
> *From:* Tony Li  *On Behalf Of *Tony Li
> *Sent:* Wednesday, November 17, 2021 5:24 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Gyan Mishra ; Aijun Wang <
> wangai...@tsinghua.org.cn>; lsr@ietf.org; Christian Hopps <
> cho...@chopps.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> Les,
>
>
>
> That’s easy.  The summary covers all addresses of all of the nodes (hosts
> and routers) in the area. It also may cover addresses within the summary
> that are not currently assigned. This is intentional since by advertising a
> summary, we gain scalability. The summary provides aggregated reachability
> throughout the network.
>
>
>
> Reachability and path selection is the responsibility of the IGP, not
> liveness.
>
>
>
> Should we not advertise a summary because a single address in the summary
> is not assigned?  No, it is up to correspondents to determine if the
> address is populated.
>
>
>
> Should we punch holes in our summary for unassigned addresses?  No, that
> would kill scalability.
>
>
>
> Should we punch holes in our summary for host failures?  That would kill
> scalability too and drag the IGP out of its role.
>
>
>
> Why would we then punch holes in the summary for member routers?  Just
> because we can?
>
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
>
>
> *[LES:] What are you proposing?*
>
>
>
> *   Les*
>
>
>
> Regards,
>
> Tony
>
>
>
>
>
>
>
> On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf.org> wrote:
>
>
>
> I think the discussion about using a separate instance is a distraction
> and we shouldn’t be debating that right now.
>
>
>
> The legitimate question is whether folks see it as appropriate to have an
> IGP based solution for the problem. How to do it using the IGP is only a
> meaningful question if we are considering using the IGP at all.
>
>
>
> In that context…it is clear that it is a legitimate use of the IGP to
> advertise summary addresses.
>
> It is also a legitimate use of the IGPs to advertise all the individual
> prefixes covered by a summary if the network operator chooses not to
> summarize.
>
> It therefore seems to me to quite legitimate for the IGP to advertise both
> a summary and changes to the reachability of individual destinations
> covered by the summary. This is still a type of prefix reachability
> advertisement.
>
>
>
> It would help me if the folks who think this is NOT a legitimate use of an
> IGP could explain why in the context of the above.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, November 17, 2021 4:32 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ;
> lsr@ietf.org; Christian Hopps ; Tony Przygienda <
> tonysi...@gmail.com>; Acee Lindem (acee) 
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> With MT separate control plane common data plane or Multi Instance
> separate control plane and separate data plane.
>
>
>
> In both transport instance styles peeling the event notification into a
> separate instance or topology how do this discrete transport instance or
> topology interact with the main instance or topology.
>
>
>
> The answer is 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

> On Nov 17, 2021, at 6:09 PM, Aijun Wang  wrote:
> 
> Hi, Christian:
> 
> Would you like to describe how to solve the problem via using the transport 
> instance? The detail interaction process within the node and the deployment  
> overhead analysis?


As A WG member:

When I said in the meeting "As a WG member, I agree" I was specifically 
referring to the gist of his statement which was that this wasn't worth putting 
into the main protocol. I'm unconvinced (again as a WG member) that there's a 
problem worth trying to solve here -- at least one that rises above the "should 
we add something to the the protocol" level.

That said, the main point that I believe I was making here was that his comment 
was a good one to make during the adoption call (or preferably before we got to 
this point), so that discussion around it could happen on the list.

Thanks,
Chris.

> If there is no such information, it is doubt whether your judgment is correct 
> or not, it is also unconvincing. Welcome also Tony gives the explanation 
> before making the assertions, as we done for PUAM solution.




> 
> 
> Aijun Wang
> China Telecom
> 
>> On Nov 17, 2021, at 22:59, Christian Hopps  wrote:
>> 
>> 
>> 
>>> On Nov 16, 2021, at 10:36 PM, Aijun Wang  wrote:
>>> 
>>> Hi, 
>>> 
>>> The followings are the responses for the comments on PUAM 
>>> draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>>> 
>>> Les:  The comment I want to make, I think the discussion on the
>>> list highlighted the fact that there's an open question,
>>> independent of whether we use the prefix unreachable
>>> draft or the Event Notification draft, as to whether this
>>> problem should be solved by the IGP or whether it should be
>>> solved by BGP, or in some other way. And I think the logical
>>> way to proceed on this is to get the consensus of the working
>>> group as to whether an IGP solution is desired first, then
>>> after we reach consensus on that, then we can start talking
>>> about which approach is the better approach. Which one
>>> should be adopted?
>>> 【WAJ】The problem is occurred due to the summary action by the ABR router in 
>>> IGP, it should be solved by IGP itself.
>>> As discussed earlier on the list, the possible use case is not limited to 
>>> BGP fast convergence.
>>> Based on the above considerations, it is not appropriated solved via BGP. 
>>> 
>>> Chris H:  Chair hat on. You've been asking for adoption for a while.
>>> The event notification draft is new. I agree with Les that
>>> in a perfect world that would be the case, but asking for
>>> adoption is one way to answer the question. It may be not
>>> the perfect way to answer that question, but it is one way.
>>> I agree without my chair hat on, I'm not sure we need this,
>>> but it's not for me to say by fiat. Acee did put something
>>> out on the list to try to engage people again. And I don't
>>> think a lot got said.
>>> 【WAJ】we have several round discussions for this topic but there is always 
>>> no conclusion at the end. 
>>>  Can the expert that reluctant to accept the new idea to give some 
>>> specific questions/problems for the current solution?
>>> Or else it is not helpful for the solve of the existing problem.
>>>  Initiate the adoption call maybe the best way to let the experts 
>>> express their opinions? 
>>>  We would like to hear the specific and detail comments for the current 
>>> solutions, not just general comments.
>>> 
>>> Acee: I didn't see much support other than from the authors. I
>>> saw one non-author support on the event notification. 
>>> 【WAJ】Does anyone not agree what we analyze/summarize at the presentation 
>>> material for the two solutions? 
>>> (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
>>>  the 5th slide)
>>> 
>>> Chris:Everyone has a right to ask for an adoption. Everyone has a
>>> right to say we shouldn't adopt this and there are the
>>> reasons. We've let people to express opinions, without
>>> seeing a lot of negative opinions it's hard not to just grant
>>> the adoption call.
>>> 【WAJ】I agree.
>>> 
>>> Tony P:   I think this is all making a trash can out of the IGP. One
>>> possible solution is to ban or encouraged maybe everyone with
>>> these kind of suggestions to go towards the service instance
>>> stuff or whatever we call it, which I think is a good idea.
>>> Just run a power line up and much lower priority. Don't trash
>>> the main protocol that holds the whole thing together.
>>> 【WAJ】Do you consider the deployment complexity for independent service 
>>> instance to transfer such thing? And also the interaction on the device 
>>> among the main IGP instance and the service insta

[Lsr] Clarification on RFC 7794

[Shraddha Hegde]

WG,


I am looking for clarification on below text in RFC 7794 sec 2.2


"Note that the Router ID advertised is always the Router ID of the

   IS-IS instance that originated the advertisement.  This would be true

   even if the prefix had been learned from another protocol (i.e., with

   the X-flag set as defined in Section 
2.1)"


If a router is re-distributing a prefix from another ISIS instance it would put 
the source router-id of the
Originating router. If the prefix is being redistributed from another protocol 
(say OSPF) the source router-id of the
Prefix would be set to the router-id of the redistributing router. Is this the 
correct interpretation?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr