Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS

[Jaideep Choudhary]

Hi Les,

Thanks for the quick response.

I also could not find anywhere in the standard documentation stating that
SYS ID of .. in IS-IS as invalid nor is there any restriction
to how to calculate the SYS ID.

Yes, there are recommendations to use MAC or IP address to calculate the
SYS ID , so it remains unique in a routing domain, but *couldn't *be found
anywhere in the standard documentation, if SYS ID *must be derived from
these addresses only*.

Having said that, in most of the cases, there would be very less
probability of SYS ID of .. being configured in a production
environment (as you also mentioned), but still, as there is no such
explicit restriction (in the standards ISO10589 or RFC 3784) to not to use
SYS ID: 0, so it can still be used as a valid SYS ID in the devices where
it is allowed to configure the NET/SYSTEM ID manually.

So in that case if some device the setting of SYS ID being 0 is considered
as invalid or illegal, that can cause some serious routing issues in a
single area multi vendor setup in ISIS.

*So, can we say that from Standards perspective SYS ID: .. is a
legal setting ?*

Regards
Jaideep

On Tue, Jun 14, 2022 at 9:59 PM Les Ginsberg (ginsberg) 
wrote:

> Jaideep –
>
>
>
> I am not aware that any standard formally defines a system-id of
> .. as invalid.
>
> If there is, it would be an ISO specification – but a perusal of ISO
> 10589, ISO 8348, and ISO 7498 did not yield any such statement.
>
> (I would be happy to be corrected if someone has a reference.)
>
>
>
> From a practical standpoint, the lack of agreement on this by all
> implementations should not represent a significant concern.
>
> Schemes which automatically populate the system-id are typically based on
> the MAC address of some NIC on the box.
>
> Another common strategy is to use the zero filled IP address of some
> loopback.
>
> In either case all zeros will not be the result.
>
>
>
> In cases where the systemid is explicitly configured, it is easy enough
> NOT to use all 0’s.
>
>
>
> HTH
>
>
>
> Les
>
>
>
> *From:* Lsr  *On Behalf Of * Jaideep Choudhary
> *Sent:* Tuesday, June 14, 2022 8:00 AM
> *To:* Tony Li 
> *Cc:* supp...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS
>
>
>
> Hi Tony,
>
>
>
> I am not looking for technical support, but looking for IETF's perspective
> regarding the system id in IS-IS.
>
>
>
> As per the RFC 3784 there is no mention about any invalid value in a
> system id.
>
>
>
> Can you please confirm whether there is any such restriction to not to use
> a SYS ID of .. as per IETF standards ?
>
>
>
> If this mailing address is not appropriate for answering this query, can
> you suggest/redirect me to the correct team from IETF ?
>
>
>
> Thanks.
>
>
>
> Regards
>
> Jaideep
>
>
>
> On Tue, Jun 14, 2022, 20:19 Tony Li  wrote:
>
>
>
> Hi,
>
>
>
> Neither of these mailing lists are appropriate for technical support.
> Please contact your vendors directly.
>
>
>
> Tony
>
>
>
>
>
> On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary <
> jaideepchoudhar...@gmail.com> wrote:
>
>
>
> Hi Team,
>
> I would like to know, whether in IS-IS, a system id can be ..
> or it is an invalid value for sys I'd ?
>
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
> mention explicitly whether SYS ID of .. could be invalid.
>
> Also as per RFC 3784, it says System id is typically of 6 bytes, but
> doesn't talk about any invalid option.
>
> The reason I am asking this is that Juniper defines a SYS ID of
> .. as invalid.
>
>
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>
>
>
> This can cause issues in inter-operability as some vendors like Cisco
> doesn't define a SYS-ID of .. as invalid.
>
> I would appreciate your response on this.
>
> Regards
>
> Jaideep Choudhary
>
>
>
> On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT, 
> wrote:
>
> Hi Jaideep,
>
> You have reached the IETF Secretariat, which is the administrative branch
> of the IETF, and as such, we are not qualified to answer your technical
> questions.
>
> You might have better luck if you try posing your question to the Link
> State Routing (LSR) Working Group (
> https://datatracker.ietf.org/wg/lsr/about/). LSR was formed by merging
> the ISIS and OSPF WGs and assigning all their existing adopted work at the
> time of chartering to LSR. Their mailing list address is lsr@ietf.org.
>
> Best regards,
> Cindy
>
> On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com wrote:
>
> Hi Team,
>
>
>
> I would like to know, whether in IS-IS, a system id can be ..
> or it is an invalid value for sys I'd ?
>
>
>
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
> mention explicitly whether SYS ID of .. could be invalid.
>
>
>
> Also as per RFC 3784, it says System id is typically of 6 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Huaimo Chen]

Hi Everyone,

I agree with Les and think #2 is better.

Best Regards,
Huaimo

From: Lsr  on behalf of Les Ginsberg (ginsberg) 

Sent: Tuesday, June 14, 2022 4:00 PM
To: John E Drake ; Les Ginsberg (ginsberg) 
; John Scudder 

Cc: Tony Li ; tom petch ; Acee Lindem 
(acee) ; lsr@ietf.org 
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - 
draft-ietf-lsr-dynamic-flooding

John -

I would be inclined to agree with you - but...to my knowledge (happy to be 
corrected...) -

There has been no interoperability testing.
It is really only possible to do interoperability testing on centralized mode 
at present, since distributed mode requires standardization/multi-vendor 
implementation of at least one algorithm - which hasn’t happened yet.
So, a significant portion of the protocol extensions remain untested. And since 
enthusiasm for this work has waned - perhaps only temporarily - it seems 
unlikely that these gaps will be closed in the immediate future.
Moving to standards track RFC with these gaps seems unwise and to some degree 
"irresponsible".

I think there are then three viable paths:

1)Continue to refresh the draft until such time as the gaps are closed or it 
becomes clear the work is more permanently not of interest
2)Capture the current contents as an Experimental RFC - noting the remaining 
work.
3)Capture the current contents as a Historic RFC - noting the remaining work.

I am not in favor of #3.
I would be OK with #1 or #2.

   Les


> -Original Message-
> From: Lsr  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
>
> Hi,
>
> I don't understand why we don't just go through the normal Standards track
> process.  I am sure there are any number of Standards track RFCs which are
> published and which are neither widely implemented nor widely deployed,
> but which may become so in the future.
>
> As Peter noted in the context of another draft, we are starting to see
> extreme growth in the size of IGPs  which to me indicates that the subject
> draft will be perceived as timely in the not too distant future.
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
> > To: John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
> dynamic-
> > flooding
> >
> > [External Email. Be cautious of content]
> >
> >
> > John -
> >
> > Thanx for the information.
> >
> > I think what is relevant as regards the dynamic-flooding draft is that we
> may be
> > prematurely burying it.
> > It is true, as Tony has stated, that the marketplace has not shown an active
> > interest in deploying this technology - but I am not yet convinced that 
> > this is
> the
> > final disposition. As the scale of IGP networks increases and the use of 
> > fast-
> > flooding is deployed, it may be that interest in dynamic-flooding is 
> > revived.
> >
> > Publishing the draft as Experimental leaves open the possibilities.
> > It could still be moved to Historic somewhere down the road if there
> continues
> > to be no deployment interest.
> >
> > I suppose it is also possible (as your post indicates) that we move it to
> historic
> > now and find a way to move it from historic if/when the need arises - but I
> > frankly find such an approach very odd.
> >
> > I do not know why we are in a rush to "bury this". I think Acee has raised a
> valid
> > point - given that there was broad consensus on the protocol extensions
> > themselves - that it would be good to formally preserve the draft content. I
> think
> > Experimental is the best way to do that.
> >
> > Les
> >
> > > -Original Message-
> > > From: John Scudder 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-dynamic- flooding
> > >
> > > Hi Les and all,
> > >
> > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > >  wrote:
> > > >
> > > > So you are suggesting that we publish something that was never
> > > > actually
> > > published as an RFC as a "historic RFC"?
> > > >
> > > > The logic of that escapes me.
> > >
> > > It so happens I recently became aware that this publication track is
> > > explicitly considered to be OK.
> > >
> 

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Robert:

Agreed. The potential usages of PUA/UPA are not only PE routers(for BGP PIC), 
but also prevalent Tunnel technologies(GRE/SRv6).
All these nodes are important and we can’t punches so many holes in the summary 
range.

Aijun Wang
China Telecom

> On Jun 14, 2022, at 22:43, Robert Raszuk  wrote:
> 
> 
> Acee, 
> 
> > Note that any good implementation will allow one to punch holes in their 
> > area ranges so that critical prefixes are advertised or
> 
> Every PE address is critical. The story that one PE can be more important 
> than any other is just to mislead you at best. 
> 
> And we are (I hope) scoped the discussion to summaries. 
> 
> I realize  PUE also wants to cover P failures so in this case each P is also 
> equally important. 
> 
> Thx,
> R,
> 
> 
>> On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee)  wrote:
>> Speaking as WG member:
>> 
>>  
>> 
>> From: Lsr  on behalf of Robert Raszuk 
>> 
>> Date: Tuesday, June 14, 2022 at 9:27 AM
>> To: Christian Hopps 
>> Cc: Gunter Van de Velde , lsr , 
>> "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 
>> , 
>> draft-wang-lsr-prefix-unreachable-annoucement 
>> 
>> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>> 
>>  
>> 
>> All,
>> 
>>  
>> 
>> > What is wrong with simply not doing summaries
>> 
>>  
>> 
>> What's wrong is that you are reaching the scaling issue much sooner than 
>> when you inject summaries. 
>> 
>>  
>> 
>> Note that any good implementation will allow one to punch holes in their 
>> area ranges so that critical prefixes are advertised or included in the 
>> range existence criteria.
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee
>> 
>>  
>> 
>>  
>> 
>> Note that the number of those host routes is flooded irrespective of the 
>> actual need everywhere based on the sick assumption that perhaps they may be 
>> needed there. There is no today to the best of my knowledge controlled 
>> leaking to only subset to what is needed. 
>> 
>>  
>> 
>> But this is not the main worry. Main worry is that in redundant networks you 
>> are seeing many copies of the very same route being flooded all over the 
>> place. So in a not so big 1000 node network the number of host routes may 
>> exceed 8000 easily. cri
>> 
>>  
>> 
>> Sure when things are stable all is cool. But we should prepare for the 
>> worst, not the best. In fact, the ability to encapsulate to an aggregate 
>> switch IP (GRE or UDP) or nowadays SRv6 has been one of the strongest 
>> advantages. 
>> 
>>  
>> 
>> So as started before the problem does exist. Neither PULSE nor PUE solve it 
>> which are both limited to PE failures detection which is not enough (maybe 
>> even not worth). But PE-CE failures need to be signalled in the case of 
>> injecting summaries. Maybe as I said in previous msg just BGP withdrawal is 
>> fine. If not we should seek a solution which addresses the real problem, not 
>> an infrequent one. 
>> 
>>  
>> 
>> Best,
>> 
>> R.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps  wrote:
>> 
>> 
>> 
>> > On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> >  wrote:
>> > 
>> > What is wrong with simply not doing summaries and forget about these PUAs 
>> > to pinch holes in the summary prefixes? this worked very well during last 
>> > two decennia. Are we not over-engineering with PUAs?
>> 
>> 100% yes, IMO.
>> 
>> Thanks,
>> Chris.
>> [as wg-member]
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Robert Raszuk]

> Well, we can blame marketing all we want.  All I know is that we, as a
> group, failed to come together and present a unified front with
> interoperable implementations. That left us in a position where marketing
> is pushing rocks up hills and customers are waiting for the dust to settle.


I am not blaming marketing here. Real engineers never listen to marketing.

The main issue why BGP won in some MSDCs was that it was much easier (and
cheaper) to deploy on OEM white boxes then any alternative scalable IGP
(read use open source).

So yes - link state IGPs were late for MSDCs. Petr's draft then RFC was
like a hammer to this as well. But many use BGP as an underlay without
fully realizing the pros and cons. Some run BGP purely from positioning
perspective as they can be seen "weaker" as the largest hyperscalers. Many
still run BGP services with no hierarchy and clean decoupling.

IMHO even for many DCs this is still not the lost battle if positioned IGPs
right. So let's progress this as Experimental and clearly explain the
benefits if given implementation supports this.

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Robert,

> > So, can we PLEASE stop beating a dead horse?
> 
> Are you stating that computing dynamic flooding topologies has no use case 
> outside of MSDCs or for that matter ANY-DCs ? 


There may be a zillion use cases. But there is not critical mass for deploying 
this feature or other flooding reduction features. The time to solve this 
problem was back BEFORE people decided to repurpose BGP to solve their 
problems.  Now, it’s a classic ‘installed base’ problem. People will only 
consider alternatives if an alternative path represents less pain than the 
established path. We’re not there. BGP wins.


> PS. It is true that folks even running 10 racks think BGP is the only choice 
> for the underlay but to me this is failure of deployment folks in vendors to 
> properly position each dynamic routing protocol then nothing else. 


Well, we can blame marketing all we want.  All I know is that we, as a group, 
failed to come together and present a unified front with interoperable 
implementations. That left us in a position where marketing is pushing rocks up 
hills and customers are waiting for the dust to settle. 

T

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Yingzhen Qu]

I support option #2, publishing as an experimental RFC. Later it can be
moved to either standard or historic.

Thanks,
Yingzhen

On Tue, Jun 14, 2022 at 1:00 PM Les Ginsberg (ginsberg)  wrote:

> John -
>
> I would be inclined to agree with you - but...to my knowledge (happy to be
> corrected...) -
>
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized
> mode at present, since distributed mode requires
> standardization/multi-vendor implementation of at least one algorithm -
> which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And
> since enthusiasm for this work has waned - perhaps only temporarily - it
> seems unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some
> degree "irresponsible".
>
> I think there are then three viable paths:
>
> 1)Continue to refresh the draft until such time as the gaps are closed or
> it becomes clear the work is more permanently not of interest
> 2)Capture the current contents as an Experimental RFC - noting the
> remaining work.
> 3)Capture the current contents as a Historic RFC - noting the remaining
> work.
>
> I am not in favor of #3.
> I would be OK with #1 or #2.
>
>Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ; John
> > Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> draft-ietf-lsr-dynamic-
> > flooding
> >
> > Hi,
> >
> > I don't understand why we don't just go through the normal Standards
> track
> > process.  I am sure there are any number of Standards track RFCs which
> are
> > published and which are neither widely implemented nor widely deployed,
> > but which may become so in the future.
> >
> > As Peter noted in the context of another draft, we are starting to see
> > extreme growth in the size of IGPs  which to me indicates that the
> subject
> > draft will be perceived as timely in the not too distant future.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
> > dynamic-
> > > flooding
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > John -
> > >
> > > Thanx for the information.
> > >
> > > I think what is relevant as regards the dynamic-flooding draft is that
> we
> > may be
> > > prematurely burying it.
> > > It is true, as Tony has stated, that the marketplace has not shown an
> active
> > > interest in deploying this technology - but I am not yet convinced
> that this is
> > the
> > > final disposition. As the scale of IGP networks increases and the use
> of fast-
> > > flooding is deployed, it may be that interest in dynamic-flooding is
> revived.
> > >
> > > Publishing the draft as Experimental leaves open the possibilities.
> > > It could still be moved to Historic somewhere down the road if there
> > continues
> > > to be no deployment interest.
> > >
> > > I suppose it is also possible (as your post indicates) that we move it
> to
> > historic
> > > now and find a way to move it from historic if/when the need arises -
> but I
> > > frankly find such an approach very odd.
> > >
> > > I do not know why we are in a rush to "bury this". I think Acee has
> raised a
> > valid
> > > point - given that there was broad consensus on the protocol extensions
> > > themselves - that it would be good to formally preserve the draft
> content. I
> > think
> > > Experimental is the best way to do that.
> > >
> > > Les
> > >
> > > > -Original Message-
> > > > From: John Scudder 
> > > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > > To: Les Ginsberg (ginsberg) 
> > > > Cc: Tony Li ; tom petch ; Acee
> > > > Lindem (acee) ; lsr@ietf.org
> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > > draft-ietf-lsr-dynamic- flooding
> > > >
> > > > Hi Les and all,
> > > >
> > > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > > >  wrote:
> > > > >
> > > > > So you are suggesting that we publish something that was never
> > > > > actually
> > > > published as an RFC as a "historic RFC"?
> > > > >
> > > > > The logic of that escapes me.
> > > >
> > > > It so happens I recently became aware that this publication track is
> > > > explicitly considered to be OK.
> > > >
> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > > > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> > > l3RWY9vSXdEA8b
> > > >
> > >
> > 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Robert Raszuk]

Hi Tony,

> So, can we PLEASE stop beating a dead horse?

Are you stating that computing dynamic flooding topologies has no use case
outside of MSDCs or for that matter ANY-DCs ?

Thx,
R.

PS. It is true that folks even running 10 racks think BGP is the only
choice for the underlay but to me this is failure of deployment folks in
vendors to properly position each dynamic routing protocol then nothing
else.


On Tue, Jun 14, 2022 at 11:02 PM Tony Li  wrote:

>
> Gyan,
>
> Cisco has (reportedly) implemented this, but done so with their own
> proprietary, undocumented distributed algorithm.
>
> The responses that I have seen from operators have been somewhat
> disappointing:
>
> “There is no  way that I would ever let a  IGP into
> my data center.”
>
> Others have been more polite, but similarly dismissive.
>
> The fact of the matter is that there is an installed base of BGP and folks
> are not open to experimenting with anything else.
>
> So, can we PLEASE stop beating a dead horse?
>
> Tony
>
>
> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
>
> All
>
> I agree this is important work for operators in DC networks  NVO CLOS
> architecture with extremely dense fabrics and massively scaled out spines.
>
> I agree we can move forward with progressing with only ISIS being
> implemented.
>
> I do think that after the draft is published hopefully implementations
> include OSPF as well as there is a lot of OSPF used by operators.
>
> NVO CLOS architecture I would say is being universally being deployed as
> defacto standard  in the DC arena.  As well as most operators don’t want to
> go for the BGP only solution in the DC due to the complexity as well as
> having to provision many public ASNs.
>
> I support #1 first followed by #2.
>
> So far we have Arista implementation, and we have both Cisco and Juniper
> Co-Authors as  well  on the draft.
>
> I think we have a good chance at #1 - Standards track.
>
> Les & Tony & Tony
>
> What is the chance of getting this implemented by Cisco & Juniper?
>
>
> We also have a few major stakeholders in the industry supporting the
> draft, Verizon, ATT and CenturyLink as co-authors which I think shows how
> important this draft is for the industry.
>
> Kind Regards
>
> Gyan
>
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake  40juniper@dmarc.ietf.org> wrote:
>
>> Les,
>>
>> I'm happy with either 1 or 2.  It's good work and I think it will become
>> important.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>
>> Juniper Business Use Only
>>
>> > -Original Message-
>> > From: Les Ginsberg (ginsberg) 
>> > Sent: Tuesday, June 14, 2022 4:01 PM
>> > To: John E Drake ; Les Ginsberg (ginsberg)
>> > ; John Scudder 
>> > Cc: Tony Li ; tom petch ; Acee
>> Lindem
>> > (acee) ; lsr@ietf.org
>> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs -
>> draft-ietf-lsr-dynamic-
>> > flooding
>> >
>> > [External Email. Be cautious of content]
>> >
>> >
>> > John -
>> >
>> > I would be inclined to agree with you - but...to my knowledge (happy to
>> be
>> > corrected...) -
>> >
>> > There has been no interoperability testing.
>> > It is really only possible to do interoperability testing on
>> centralized mode at
>> > present, since distributed mode requires standardization/multi-vendor
>> > implementation of at least one algorithm - which hasn’t happened yet.
>> > So, a significant portion of the protocol extensions remain untested.
>> And since
>> > enthusiasm for this work has waned - perhaps only temporarily - it seems
>> > unlikely that these gaps will be closed in the immediate future.
>> > Moving to standards track RFC with these gaps seems unwise and to some
>> > degree "irresponsible".
>> >
>> > I think there are then three viable paths:
>> >
>> > 1)Continue to refresh the draft until such time as the gaps are closed
>> or it
>> > becomes clear the work is more permanently not of interest 2)Capture the
>> > current contents as an Experimental RFC - noting the remaining work.
>> > 3)Capture the current contents as a Historic RFC - noting the remaining
>> work.
>> >
>> > I am not in favor of #3.
>> > I would be OK with #1 or #2.
>> >
>> >Les
>> >
>> >
>> > > -Original Message-
>> > > From: Lsr  On Behalf Of John E Drake
>> > > Sent: Tuesday, June 14, 2022 11:23 AM
>> > > To: Les Ginsberg (ginsberg) ;
>> > > John Scudder 
>> > > Cc: Tony Li ; tom petch ; Acee
>> > > Lindem (acee) ; lsr@ietf.org
>> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
>> > > draft-ietf-lsr-dynamic- flooding
>> > >
>> > > Hi,
>> > >
>> > > I don't understand why we don't just go through the normal Standards
>> > > track process.  I am sure there are any number of Standards track RFCs
>> > > which are published and which are neither widely implemented nor
>> > > widely deployed, but which may become so in the future.
>> > >
>> > > As Peter noted in the context of another draft, we are starting to see
>> > > extreme growth in the size of IGPs  which to me indicates that the
>> > > subject 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Gyan,

Cisco has (reportedly) implemented this, but done so with their own 
proprietary, undocumented distributed algorithm.

The responses that I have seen from operators have been somewhat disappointing:

“There is no  way that I would ever let a  IGP 
into my data center.”

Others have been more polite, but similarly dismissive.

The fact of the matter is that there is an installed base of BGP and folks are 
not open to experimenting with anything else.

So, can we PLEASE stop beating a dead horse?

Tony


> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
> 
> All
> 
> I agree this is important work for operators in DC networks  NVO CLOS 
> architecture with extremely dense fabrics and massively scaled out spines.
> 
> I agree we can move forward with progressing with only ISIS being implemented.
> 
> I do think that after the draft is published hopefully implementations 
> include OSPF as well as there is a lot of OSPF used by operators.  
> 
> NVO CLOS architecture I would say is being universally being deployed as 
> defacto standard  in the DC arena.  As well as most operators don’t want to 
> go for the BGP only solution in the DC due to the complexity as well as 
> having to provision many public ASNs.
> 
> I support #1 first followed by #2.
> 
> So far we have Arista implementation, and we have both Cisco and Juniper 
> Co-Authors as  well  on the draft.  
> 
> I think we have a good chance at #1 - Standards track.
> 
> Les & Tony & Tony
> 
> What is the chance of getting this implemented by Cisco & Juniper?
> 
> 
> We also have a few major stakeholders in the industry supporting the draft, 
> Verizon, ATT and CenturyLink as co-authors which I think shows how important 
> this draft is for the industry.
> 
> Kind Regards 
> 
> Gyan
> 
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
> Les,
> 
> I'm happy with either 1 or 2.  It's good work and I think it will become 
> important.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Les Ginsberg (ginsberg)  > >
> > Sent: Tuesday, June 14, 2022 4:01 PM
> > To: John E Drake mailto:jdr...@juniper.net>>; Les 
> > Ginsberg (ginsberg)
> > mailto:ginsb...@cisco.com>>; John Scudder 
> > mailto:j...@juniper.net>>
> > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > mailto:ie...@btconnect.com>>; Acee Lindem
> > (acee) mailto:a...@cisco.com>>; lsr@ietf.org 
> > 
> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs - 
> > draft-ietf-lsr-dynamic-
> > flooding
> > 
> > [External Email. Be cautious of content]
> > 
> > 
> > John -
> > 
> > I would be inclined to agree with you - but...to my knowledge (happy to be
> > corrected...) -
> > 
> > There has been no interoperability testing.
> > It is really only possible to do interoperability testing on centralized 
> > mode at
> > present, since distributed mode requires standardization/multi-vendor
> > implementation of at least one algorithm - which hasn’t happened yet.
> > So, a significant portion of the protocol extensions remain untested. And 
> > since
> > enthusiasm for this work has waned - perhaps only temporarily - it seems
> > unlikely that these gaps will be closed in the immediate future.
> > Moving to standards track RFC with these gaps seems unwise and to some
> > degree "irresponsible".
> > 
> > I think there are then three viable paths:
> > 
> > 1)Continue to refresh the draft until such time as the gaps are closed or it
> > becomes clear the work is more permanently not of interest 2)Capture the
> > current contents as an Experimental RFC - noting the remaining work.
> > 3)Capture the current contents as a Historic RFC - noting the remaining 
> > work.
> > 
> > I am not in favor of #3.
> > I would be OK with #1 or #2.
> > 
> >Les
> > 
> > 
> > > -Original Message-
> > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf 
> > > Of John E Drake
> > > Sent: Tuesday, June 14, 2022 11:23 AM
> > > To: Les Ginsberg (ginsberg)  > > >;
> > > John Scudder  > > >
> > > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > > mailto:ie...@btconnect.com>>; Acee
> > > Lindem (acee) mailto:a...@cisco.com>>; lsr@ietf.org 
> > > 
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-dynamic- flooding
> > >
> > > Hi,
> > >
> > > I don't understand why we don't just go through the normal Standards
> > > track process.  I am sure there are any number of Standards track RFCs
> > > which are published and which are neither widely implemented nor
> > > widely deployed, but which may become so in the future.
> > >
> > > As Peter noted in the context of another draft, we are starting to see
> > > extreme growth in the size of IGPs  which to me indicates that the
> > > subject draft will be perceived as timely 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John Scudder]

I’ll point out that option 2 frees us from having to run an annual exception 
process to renew the code points. I mean, if the draft is being actively worked 
then of course keep it in draft, but don’t just version-bump it ad infinitum 
(it wasn’t clear to me if that was what you meant by “continue to refresh”). 

Thanks,

—John

> On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> John -
> 
> I would be inclined to agree with you - but...to my knowledge (happy to be 
> corrected...) -
> 
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized mode 
> at present, since distributed mode requires standardization/multi-vendor 
> implementation of at least one algorithm - which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And 
> since enthusiasm for this work has waned - perhaps only temporarily - it 
> seems unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some degree 
> "irresponsible".
> 
> I think there are then three viable paths:
> 
> 1)Continue to refresh the draft until such time as the gaps are closed or it 
> becomes clear the work is more permanently not of interest
> 2)Capture the current contents as an Experimental RFC - noting the remaining 
> work.
> 3)Capture the current contents as a Historic RFC - noting the remaining work.
> 
> I am not in favor of #3.
> I would be OK with #1 or #2.
> 
>   Les
> 
> 
>> -Original Message-
>> From: Lsr  On Behalf Of John E Drake
>> Sent: Tuesday, June 14, 2022 11:23 AM
>> To: Les Ginsberg (ginsberg) ; John
>> Scudder 
>> Cc: Tony Li ; tom petch ; Acee
>> Lindem (acee) ; lsr@ietf.org
>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
>> flooding
>> 
>> Hi,
>> 
>> I don't understand why we don't just go through the normal Standards track
>> process.  I am sure there are any number of Standards track RFCs which are
>> published and which are neither widely implemented nor widely deployed,
>> but which may become so in the future.
>> 
>> As Peter noted in the context of another draft, we are starting to see
>> extreme growth in the size of IGPs  which to me indicates that the subject
>> draft will be perceived as timely in the not too distant future.
>> 
>> Yours Irrespectively,
>> 
>> John
>> 
>> 
>> Juniper Business Use Only
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, June 14, 2022 12:19 PM
>>> To: John Scudder 
>>> Cc: Tony Li ; tom petch ; Acee
>> Lindem
>>> (acee) ; lsr@ietf.org
>>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
>> dynamic-
>>> flooding
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> John -
>>> 
>>> Thanx for the information.
>>> 
>>> I think what is relevant as regards the dynamic-flooding draft is that we
>> may be
>>> prematurely burying it.
>>> It is true, as Tony has stated, that the marketplace has not shown an active
>>> interest in deploying this technology - but I am not yet convinced that 
>>> this is
>> the
>>> final disposition. As the scale of IGP networks increases and the use of 
>>> fast-
>>> flooding is deployed, it may be that interest in dynamic-flooding is 
>>> revived.
>>> 
>>> Publishing the draft as Experimental leaves open the possibilities.
>>> It could still be moved to Historic somewhere down the road if there
>> continues
>>> to be no deployment interest.
>>> 
>>> I suppose it is also possible (as your post indicates) that we move it to
>> historic
>>> now and find a way to move it from historic if/when the need arises - but I
>>> frankly find such an approach very odd.
>>> 
>>> I do not know why we are in a rush to "bury this". I think Acee has raised a
>> valid
>>> point - given that there was broad consensus on the protocol extensions
>>> themselves - that it would be good to formally preserve the draft content. I
>> think
>>> Experimental is the best way to do that.
>>> 
>>>Les
>>> 
 -Original Message-
 From: John Scudder 
 Sent: Tuesday, June 14, 2022 7:46 AM
 To: Les Ginsberg (ginsberg) 
 Cc: Tony Li ; tom petch ; Acee
 Lindem (acee) ; lsr@ietf.org
 Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
 draft-ietf-lsr-dynamic- flooding
 
 Hi Les and all,
 
> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
  wrote:
> 
> So you are suggesting that we publish something that was never
> actually
 published as an RFC as a "historic RFC"?
> 
> The logic of that escapes me.
 
 It so happens I recently became aware that this publication track is
 explicitly considered to be OK.
 
>> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
 tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
>>> l3RWY9vSXdEA8b
 
>>> 
>> 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Gyan Mishra]

All

I agree this is important work for operators in DC networks  NVO CLOS
architecture with extremely dense fabrics and massively scaled out spines.

I agree we can move forward with progressing with only ISIS being
implemented.

I do think that after the draft is published hopefully implementations
include OSPF as well as there is a lot of OSPF used by operators.

NVO CLOS architecture I would say is being universally being deployed as
defacto standard  in the DC arena.  As well as most operators don’t want to
go for the BGP only solution in the DC due to the complexity as well as
having to provision many public ASNs.

I support #1 first followed by #2.

So far we have Arista implementation, and we have both Cisco and Juniper
Co-Authors as  well  on the draft.

I think we have a good chance at #1 - Standards track.

Les & Tony & Tony

What is the chance of getting this implemented by Cisco & Juniper?


We also have a few major stakeholders in the industry supporting the draft,
Verizon, ATT and CenturyLink as co-authors which I think shows how
important this draft is for the industry.

Kind Regards

Gyan

On Tue, Jun 14, 2022 at 4:05 PM John E Drake  wrote:

> Les,
>
> I'm happy with either 1 or 2.  It's good work and I think it will become
> important.
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: Les Ginsberg (ginsberg) 
> > Sent: Tuesday, June 14, 2022 4:01 PM
> > To: John E Drake ; Les Ginsberg (ginsberg)
> > ; John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; lsr@ietf.org
> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs -
> draft-ietf-lsr-dynamic-
> > flooding
> >
> > [External Email. Be cautious of content]
> >
> >
> > John -
> >
> > I would be inclined to agree with you - but...to my knowledge (happy to
> be
> > corrected...) -
> >
> > There has been no interoperability testing.
> > It is really only possible to do interoperability testing on centralized
> mode at
> > present, since distributed mode requires standardization/multi-vendor
> > implementation of at least one algorithm - which hasn’t happened yet.
> > So, a significant portion of the protocol extensions remain untested.
> And since
> > enthusiasm for this work has waned - perhaps only temporarily - it seems
> > unlikely that these gaps will be closed in the immediate future.
> > Moving to standards track RFC with these gaps seems unwise and to some
> > degree "irresponsible".
> >
> > I think there are then three viable paths:
> >
> > 1)Continue to refresh the draft until such time as the gaps are closed
> or it
> > becomes clear the work is more permanently not of interest 2)Capture the
> > current contents as an Experimental RFC - noting the remaining work.
> > 3)Capture the current contents as a Historic RFC - noting the remaining
> work.
> >
> > I am not in favor of #3.
> > I would be OK with #1 or #2.
> >
> >Les
> >
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of John E Drake
> > > Sent: Tuesday, June 14, 2022 11:23 AM
> > > To: Les Ginsberg (ginsberg) ;
> > > John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-dynamic- flooding
> > >
> > > Hi,
> > >
> > > I don't understand why we don't just go through the normal Standards
> > > track process.  I am sure there are any number of Standards track RFCs
> > > which are published and which are neither widely implemented nor
> > > widely deployed, but which may become so in the future.
> > >
> > > As Peter noted in the context of another draft, we are starting to see
> > > extreme growth in the size of IGPs  which to me indicates that the
> > > subject draft will be perceived as timely in the not too distant
> future.
> > >
> > > Yours Irrespectively,
> > >
> > > John
> > >
> > >
> > > Juniper Business Use Only
> > >
> > > > -Original Message-
> > > > From: Lsr  On Behalf Of Les Ginsberg
> > > > (ginsberg)
> > > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > > To: John Scudder 
> > > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem
> > > > (acee) ; lsr@ietf.org
> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > > draft-ietf-lsr-
> > > dynamic-
> > > > flooding
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > John -
> > > >
> > > > Thanx for the information.
> > > >
> > > > I think what is relevant as regards the dynamic-flooding draft is
> > > > that we
> > > may be
> > > > prematurely burying it.
> > > > It is true, as Tony has stated, that the marketplace has not shown
> > > > an active interest in deploying this technology - but I am not yet
> > > > convinced that this is
> > > the
> > > > final disposition. As the scale of IGP networks increases and the
> > > > use of fast- flooding is deployed, it may be that interest in
> dynamic-flooding
> > is revived.
> > > >
> > > > Publishing the draft as 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John E Drake]

Les,

I'm happy with either 1 or 2.  It's good work and I think it will become 
important.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, June 14, 2022 4:01 PM
> To: John E Drake ; Les Ginsberg (ginsberg)
> ; John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; lsr@ietf.org
> Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> [External Email. Be cautious of content]
> 
> 
> John -
> 
> I would be inclined to agree with you - but...to my knowledge (happy to be
> corrected...) -
> 
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized mode 
> at
> present, since distributed mode requires standardization/multi-vendor
> implementation of at least one algorithm - which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And 
> since
> enthusiasm for this work has waned - perhaps only temporarily - it seems
> unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some
> degree "irresponsible".
> 
> I think there are then three viable paths:
> 
> 1)Continue to refresh the draft until such time as the gaps are closed or it
> becomes clear the work is more permanently not of interest 2)Capture the
> current contents as an Experimental RFC - noting the remaining work.
> 3)Capture the current contents as a Historic RFC - noting the remaining work.
> 
> I am not in favor of #3.
> I would be OK with #1 or #2.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ;
> > John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > draft-ietf-lsr-dynamic- flooding
> >
> > Hi,
> >
> > I don't understand why we don't just go through the normal Standards
> > track process.  I am sure there are any number of Standards track RFCs
> > which are published and which are neither widely implemented nor
> > widely deployed, but which may become so in the future.
> >
> > As Peter noted in the context of another draft, we are starting to see
> > extreme growth in the size of IGPs  which to me indicates that the
> > subject draft will be perceived as timely in the not too distant future.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Les Ginsberg
> > > (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-
> > dynamic-
> > > flooding
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > John -
> > >
> > > Thanx for the information.
> > >
> > > I think what is relevant as regards the dynamic-flooding draft is
> > > that we
> > may be
> > > prematurely burying it.
> > > It is true, as Tony has stated, that the marketplace has not shown
> > > an active interest in deploying this technology - but I am not yet
> > > convinced that this is
> > the
> > > final disposition. As the scale of IGP networks increases and the
> > > use of fast- flooding is deployed, it may be that interest in 
> > > dynamic-flooding
> is revived.
> > >
> > > Publishing the draft as Experimental leaves open the possibilities.
> > > It could still be moved to Historic somewhere down the road if there
> > continues
> > > to be no deployment interest.
> > >
> > > I suppose it is also possible (as your post indicates) that we move
> > > it to
> > historic
> > > now and find a way to move it from historic if/when the need arises
> > > - but I frankly find such an approach very odd.
> > >
> > > I do not know why we are in a rush to "bury this". I think Acee has
> > > raised a
> > valid
> > > point - given that there was broad consensus on the protocol
> > > extensions themselves - that it would be good to formally preserve
> > > the draft content. I
> > think
> > > Experimental is the best way to do that.
> > >
> > > Les
> > >
> > > > -Original Message-
> > > > From: John Scudder 
> > > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > > To: Les Ginsberg (ginsberg) 
> > > > Cc: Tony Li ; tom petch ;
> > > > Acee Lindem (acee) ; lsr@ietf.org
> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > > draft-ietf-lsr-dynamic- flooding
> > > >
> > > > Hi Les and all,
> > > >
> > > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > > >  wrote:
> > > > >
> > > > > So you are suggesting that we publish something that was never
> > > > > actually
> > > > published as an RFC as a "historic RFC"?
> > > > >
> > > > > The logic of that escapes 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Acee Lindem (acee)]

I agree with Les and would add that I don't think there has been much attention 
to the OSPF and OSPFv3 extensions (other than some review). While we don't 
require implementations for every IGP extension, we usually do for major ones 
such as this . 

Thanks,
Acee

On 6/14/22, 4:00 PM, "Les Ginsberg (ginsberg)"  wrote:

John -

I would be inclined to agree with you - but...to my knowledge (happy to be 
corrected...) -

There has been no interoperability testing.
It is really only possible to do interoperability testing on centralized 
mode at present, since distributed mode requires standardization/multi-vendor 
implementation of at least one algorithm - which hasn’t happened yet.
So, a significant portion of the protocol extensions remain untested. And 
since enthusiasm for this work has waned - perhaps only temporarily - it seems 
unlikely that these gaps will be closed in the immediate future.
Moving to standards track RFC with these gaps seems unwise and to some 
degree "irresponsible".

I think there are then three viable paths:

1)Continue to refresh the draft until such time as the gaps are closed or 
it becomes clear the work is more permanently not of interest
2)Capture the current contents as an Experimental RFC - noting the 
remaining work.
3)Capture the current contents as a Historic RFC - noting the remaining 
work.

I am not in favor of #3.
I would be OK with #1 or #2.

   Les


> -Original Message-
> From: Lsr  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - 
draft-ietf-lsr-dynamic-
> flooding
> 
> Hi,
> 
> I don't understand why we don't just go through the normal Standards track
> process.  I am sure there are any number of Standards track RFCs which are
> published and which are neither widely implemented nor widely deployed,
> but which may become so in the future.
> 
> As Peter noted in the context of another draft, we are starting to see
> extreme growth in the size of IGPs  which to me indicates that the subject
> draft will be perceived as timely in the not too distant future.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
> > To: John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
> dynamic-
> > flooding
> >
> > [External Email. Be cautious of content]
> >
> >
> > John -
> >
> > Thanx for the information.
> >
> > I think what is relevant as regards the dynamic-flooding draft is that 
we
> may be
> > prematurely burying it.
> > It is true, as Tony has stated, that the marketplace has not shown an 
active
> > interest in deploying this technology - but I am not yet convinced that 
this is
> the
> > final disposition. As the scale of IGP networks increases and the use 
of fast-
> > flooding is deployed, it may be that interest in dynamic-flooding is 
revived.
> >
> > Publishing the draft as Experimental leaves open the possibilities.
> > It could still be moved to Historic somewhere down the road if there
> continues
> > to be no deployment interest.
> >
> > I suppose it is also possible (as your post indicates) that we move it 
to
> historic
> > now and find a way to move it from historic if/when the need arises - 
but I
> > frankly find such an approach very odd.
> >
> > I do not know why we are in a rush to "bury this". I think Acee has 
raised a
> valid
> > point - given that there was broad consensus on the protocol extensions
> > themselves - that it would be good to formally preserve the draft 
content. I
> think
> > Experimental is the best way to do that.
> >
> > Les
> >
> > > -Original Message-
> > > From: John Scudder 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-dynamic- flooding
> > >
> > > Hi Les and all,
> > >
> > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > >  wrote:
> > > >
> > > > So you are suggesting that we publish something that was never
> > > > actually
> > > published as an RFC as a "historic RFC"?
> > > >
> > > > The logic of that escapes me.
> > >
> > > It so happens I recently 

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Les Ginsberg (ginsberg)]

John -

I would be inclined to agree with you - but...to my knowledge (happy to be 
corrected...) -

There has been no interoperability testing.
It is really only possible to do interoperability testing on centralized mode 
at present, since distributed mode requires standardization/multi-vendor 
implementation of at least one algorithm - which hasn’t happened yet.
So, a significant portion of the protocol extensions remain untested. And since 
enthusiasm for this work has waned - perhaps only temporarily - it seems 
unlikely that these gaps will be closed in the immediate future.
Moving to standards track RFC with these gaps seems unwise and to some degree 
"irresponsible".

I think there are then three viable paths:

1)Continue to refresh the draft until such time as the gaps are closed or it 
becomes clear the work is more permanently not of interest
2)Capture the current contents as an Experimental RFC - noting the remaining 
work.
3)Capture the current contents as a Historic RFC - noting the remaining work.

I am not in favor of #3.
I would be OK with #1 or #2.

   Les


> -Original Message-
> From: Lsr  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> Hi,
> 
> I don't understand why we don't just go through the normal Standards track
> process.  I am sure there are any number of Standards track RFCs which are
> published and which are neither widely implemented nor widely deployed,
> but which may become so in the future.
> 
> As Peter noted in the context of another draft, we are starting to see
> extreme growth in the size of IGPs  which to me indicates that the subject
> draft will be perceived as timely in the not too distant future.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
> > To: John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
> dynamic-
> > flooding
> >
> > [External Email. Be cautious of content]
> >
> >
> > John -
> >
> > Thanx for the information.
> >
> > I think what is relevant as regards the dynamic-flooding draft is that we
> may be
> > prematurely burying it.
> > It is true, as Tony has stated, that the marketplace has not shown an active
> > interest in deploying this technology - but I am not yet convinced that 
> > this is
> the
> > final disposition. As the scale of IGP networks increases and the use of 
> > fast-
> > flooding is deployed, it may be that interest in dynamic-flooding is 
> > revived.
> >
> > Publishing the draft as Experimental leaves open the possibilities.
> > It could still be moved to Historic somewhere down the road if there
> continues
> > to be no deployment interest.
> >
> > I suppose it is also possible (as your post indicates) that we move it to
> historic
> > now and find a way to move it from historic if/when the need arises - but I
> > frankly find such an approach very odd.
> >
> > I do not know why we are in a rush to "bury this". I think Acee has raised a
> valid
> > point - given that there was broad consensus on the protocol extensions
> > themselves - that it would be good to formally preserve the draft content. I
> think
> > Experimental is the best way to do that.
> >
> > Les
> >
> > > -Original Message-
> > > From: John Scudder 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-dynamic- flooding
> > >
> > > Hi Les and all,
> > >
> > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> > >  wrote:
> > > >
> > > > So you are suggesting that we publish something that was never
> > > > actually
> > > published as an RFC as a "historic RFC"?
> > > >
> > > > The logic of that escapes me.
> > >
> > > It so happens I recently became aware that this publication track is
> > > explicitly considered to be OK.
> > >
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> > l3RWY9vSXdEA8b
> > >
> >
> Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSw
> HRw
> > YyGo$
> > > historic-2014-07-20/ sez
> > >
> > > "An RFC may be published directly as Historic, with no earlier status
> > > to change (see, for example, RFC 4870). This is usually done to
> > > document ideas that were considered and discarded, or protocols that
> > > were already historic when it was decided to document them. Those
> > > publications are handled as are any other RFCs.”
> > >
> > > $0.02,
> > >
> > > —John

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John E Drake]

Hi,

I don't understand why we don't just go through the normal Standards track 
process.  I am sure there are any number of Standards track RFCs which are 
published and which are neither widely implemented nor widely deployed, but 
which may become so in the future.  

As Peter noted in the context of another draft, we are starting to see extreme 
growth in the size of IGPs  which to me indicates that the subject draft will 
be perceived as timely in the not too distant future.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, June 14, 2022 12:19 PM
> To: John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> [External Email. Be cautious of content]
> 
> 
> John -
> 
> Thanx for the information.
> 
> I think what is relevant as regards the dynamic-flooding draft is that we may 
> be
> prematurely burying it.
> It is true, as Tony has stated, that the marketplace has not shown an active
> interest in deploying this technology - but I am not yet convinced that this 
> is the
> final disposition. As the scale of IGP networks increases and the use of fast-
> flooding is deployed, it may be that interest in dynamic-flooding is revived.
> 
> Publishing the draft as Experimental leaves open the possibilities.
> It could still be moved to Historic somewhere down the road if there continues
> to be no deployment interest.
> 
> I suppose it is also possible (as your post indicates) that we move it to 
> historic
> now and find a way to move it from historic if/when the need arises - but I
> frankly find such an approach very odd.
> 
> I do not know why we are in a rush to "bury this". I think Acee has raised a 
> valid
> point - given that there was broad consensus on the protocol extensions
> themselves - that it would be good to formally preserve the draft content. I 
> think
> Experimental is the best way to do that.
> 
> Les
> 
> > -Original Message-
> > From: John Scudder 
> > Sent: Tuesday, June 14, 2022 7:46 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > draft-ietf-lsr-dynamic- flooding
> >
> > Hi Les and all,
> >
> > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > So you are suggesting that we publish something that was never
> > > actually
> > published as an RFC as a "historic RFC"?
> > >
> > > The logic of that escapes me.
> >
> > It so happens I recently became aware that this publication track is
> > explicitly considered to be OK.
> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> l3RWY9vSXdEA8b
> >
> Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSwHRw
> YyGo$
> > historic-2014-07-20/ sez
> >
> > "An RFC may be published directly as Historic, with no earlier status
> > to change (see, for example, RFC 4870). This is usually done to
> > document ideas that were considered and discarded, or protocols that
> > were already historic when it was decided to document them. Those
> > publications are handled as are any other RFCs.”
> >
> > $0.02,
> >
> > —John
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!GYT66d5pSskUh-
> l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQ
> pFMmp2bSwFi578Bc$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Christian Hopps]

I think Experimental is a good way to go with this as well.

Thanks,
Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:


John -

Thanx for the information.

I think what is relevant as regards the dynamic-flooding draft is that we may 
be prematurely burying it.
It is true, as Tony has stated, that the marketplace has not shown an active
interest in deploying this technology - but I am not yet convinced that this is
the final disposition. As the scale of IGP networks increases and the use of
fast-flooding is deployed, it may be that interest in dynamic-flooding is
revived.

Publishing the draft as Experimental leaves open the possibilities.
It could still be moved to Historic somewhere down the road if there continues 
to be no deployment interest.

I suppose it is also possible (as your post indicates) that we move it to
historic now and find a way to move it from historic if/when the need arises -
but I frankly find such an approach very odd.

I do not know why we are in a rush to "bury this". I think Acee has raised a
valid point - given that there was broad consensus on the protocol extensions
themselves - that it would be good to formally preserve the draft content. I
think Experimental is the best way to do that.

Les


-Original Message-
From: John Scudder 
Sent: Tuesday, June 14, 2022 7:46 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; tom petch ; Acee
Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
flooding

Hi Les and all,

> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
 wrote:
>
> So you are suggesting that we publish something that was never actually
published as an RFC as a "historic RFC"?
>
> The logic of that escapes me.

It so happens I recently became aware that this publication track is explicitly
considered to be OK.
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-
historic-2014-07-20/ sez

"An RFC may be published directly as Historic, with no earlier status to change
(see, for example, RFC 4870). This is usually done to document ideas that
were considered and discarded, or protocols that were already historic when
it was decided to document them. Those publications are handled as are any
other RFCs.”

$0.02,

—John

___
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] [rt5.ietf.org #7080] System ID in ISIS

[Les Ginsberg (ginsberg)]

Jaideep –

I am not aware that any standard formally defines a system-id of .. 
as invalid.
If there is, it would be an ISO specification – but a perusal of ISO 10589, ISO 
8348, and ISO 7498 did not yield any such statement.
(I would be happy to be corrected if someone has a reference.)

From a practical standpoint, the lack of agreement on this by all 
implementations should not represent a significant concern.
Schemes which automatically populate the system-id are typically based on the 
MAC address of some NIC on the box.
Another common strategy is to use the zero filled IP address of some loopback.
In either case all zeros will not be the result.

In cases where the systemid is explicitly configured, it is easy enough NOT to 
use all 0’s.

HTH

Les

From: Lsr  On Behalf Of Jaideep Choudhary
Sent: Tuesday, June 14, 2022 8:00 AM
To: Tony Li 
Cc: supp...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS

Hi Tony,

I am not looking for technical support, but looking for IETF's perspective 
regarding the system id in IS-IS.

As per the RFC 3784 there is no mention about any invalid value in a system id.

Can you please confirm whether there is any such restriction to not to use a 
SYS ID of .. as per IETF standards ?

If this mailing address is not appropriate for answering this query, can you 
suggest/redirect me to the correct team from IETF ?

Thanks.

Regards
Jaideep

On Tue, Jun 14, 2022, 20:19 Tony Li mailto:tony...@tony.li>> 
wrote:

Hi,

Neither of these mailing lists are appropriate for technical support.  Please 
contact your vendors directly.

Tony



On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary 
mailto:jaideepchoudhar...@gmail.com>> wrote:

Hi Team,

I would like to know, whether in IS-IS, a system id can be .. or it 
is an invalid value for sys I'd ?

As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
explicitly whether SYS ID of .. could be invalid.

Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
talk about any invalid option.

The reason I am asking this is that Juniper defines a SYS ID of .. 
as invalid.

https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html



This can cause issues in inter-operability as some vendors like Cisco doesn't 
define a SYS-ID of .. as invalid.

I would appreciate your response on this.

Regards

Jaideep Choudhary

On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT, 
mailto:supp...@ietf.org>> wrote:

Hi Jaideep,

You have reached the IETF Secretariat, which is the administrative branch of 
the IETF, and as such, we are not qualified to answer your technical questions.

You might have better luck if you try posing your question to the Link State 
Routing (LSR) Working Group (https://datatracker.ietf.org/wg/lsr/about/). LSR 
was formed by merging the ISIS and OSPF WGs and assigning all their existing 
adopted work at the time of chartering to LSR. Their mailing list address is 
lsr@ietf.org.

Best regards,
Cindy

On Mon Jun 13 10:10:54 2022, 
jaideepchoudhar...@gmail.com wrote:
Hi Team,


I would like to know, whether in IS-IS, a system id can be .. or it 
is an invalid value for sys I'd ?


As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
explicitly whether SYS ID of .. could be invalid.


Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
talk about any invalid option.


The reason I am asking this is that Juniper defines a SYS ID of .. 
as invalid.



https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html


This can cause issues in inter-operability as some vendors like Cisco doesn't 
define a SYS-ID of .. as invalid.


I would appreciate your response on this.


Regards

Jaideep Choudhary



___
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] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Les Ginsberg (ginsberg)]

John -

Thanx for the information.

I think what is relevant as regards the dynamic-flooding draft is that we may 
be prematurely burying it.
It is true, as Tony has stated, that the marketplace has not shown an active 
interest in deploying this technology - but I am not yet convinced that this is 
the final disposition. As the scale of IGP networks increases and the use of 
fast-flooding is deployed, it may be that interest in dynamic-flooding is 
revived.

Publishing the draft as Experimental leaves open the possibilities.
It could still be moved to Historic somewhere down the road if there continues 
to be no deployment interest.

I suppose it is also possible (as your post indicates) that we move it to 
historic now and find a way to move it from historic if/when the need arises - 
but I frankly find such an approach very odd.

I do not know why we are in a rush to "bury this". I think Acee has raised a 
valid point - given that there was broad consensus on the protocol extensions 
themselves - that it would be good to formally preserve the draft content. I 
think Experimental is the best way to do that.

Les

> -Original Message-
> From: John Scudder 
> Sent: Tuesday, June 14, 2022 7:46 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> Hi Les and all,
> 
> > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > So you are suggesting that we publish something that was never actually
> published as an RFC as a "historic RFC"?
> >
> > The logic of that escapes me.
> 
> It so happens I recently became aware that this publication track is 
> explicitly
> considered to be OK.
> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-
> historic-2014-07-20/ sez
> 
> "An RFC may be published directly as Historic, with no earlier status to 
> change
> (see, for example, RFC 4870). This is usually done to document ideas that
> were considered and discarded, or protocols that were already historic when
> it was decided to document them. Those publications are handled as are any
> other RFCs.”
> 
> $0.02,
> 
> —John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John Scudder]

> On Jun 14, 2022, at 8:45 AM, Acee Lindem (acee) 
>  wrote:
> 
> If an experimental technology proves successful, it will be promoted to 
> standards track. Two notable examples are GRE and PIM.
> BIER may be another that eventually become standards track.

LISP is going through this process right now, too.

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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Peter Psenak]

Hi Gunter,

please see inline:

On 14/06/2022 10:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed summaries 
hide remote area network instabilities. It is one of the perceived benefits of 
using summaries. The place in the network where this hiding takes the most 
impact upon convergence is at service nodes (PE's for L3/L2/transport) where 
due to the summarization its difficult to detect that the transport tunnel 
end-point suddenly becomes unreachable. My concern however is if it really is a 
problem that is worthy for LSR WG to solve.


the request to address the problem is coming from the field. The scale 
of the networks in the field is growing significantly and the 
summarization is being implemented to keep the prefix scale under control.





To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a preferred solution 
due to the expectation that all nodes in an area must be upgraded to support the IGP capability. From 
this operational perspective the draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is 
more elegant, as only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do have 
concerns about the number of PUA advertisements in hierarchically summarized networks (/24 (site) -> 
/20 (region) -> /16 (core)). More specific, in the /16 backbone area, how many of these PUAs will be 
floating around creating LSP LSDB update churns? How to control the potentially exponential number of 
observed PUAs from floating everywhere? (will this lead to OSPF type NSSA areas where areas will be 
purged from these PUAs for scaling stability?)


Node going down is a rare event. The expected number of UPAs at any 
given time is very small. Implementations can limit the number of UPAs 
on ABR/ASBR in case of a catastrophic events, in which case the UPAs 
would hardly help anyway.




Long story short, should we not take a step back and re-think this identified 
problem space? Is the proposed solution space not more evil as the problem 
space? We do summarization because it brings stability and reduce the number of 
link state updates within an area. And now with PUA we re-introduce additional 
link state updates (PUAs), we blow up the LSDB with information opaque to SPF 
best-path calculation. In addition there is suggestion of new state-machinery 
to track the igp reachability of 'protected' prefixes and there is maybe desire 
to contain or filter updates cross inter-area boundaries. And finally, how will 
we represent and track PUA in the RTM?


the problem space is valid, as conformed by the field. As described 
above, the number of UPAs will be low, so there is no danger of 
defeating the purpose of the summarization.




What is wrong with simply not doing summaries and forget about these PUAs to 
pinch holes in the summary prefixes? this worked very well during last two 
decennia. Are we not over-engineering with PUAs?


it's the scale of the current networks, which is growing exponentially, 
which demands the use of the summarization.



thanks,
Peter



G/



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

Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS

[Jaideep Choudhary]

Hi Tony,

I am not looking for technical support, but looking for IETF's perspective
regarding the system id in IS-IS.

As per the RFC 3784 there is no mention about any invalid value in a system
id.

Can you please confirm whether there is any such restriction to not to use
a SYS ID of .. as per IETF standards ?

If this mailing address is not appropriate for answering this query, can
you suggest/redirect me to the correct team from IETF ?

Thanks.

Regards
Jaideep


On Tue, Jun 14, 2022, 20:19 Tony Li  wrote:

>
> Hi,
>
> Neither of these mailing lists are appropriate for technical support.
> Please contact your vendors directly.
>
> Tony
>
>
> On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary <
> jaideepchoudhar...@gmail.com> wrote:
>
> Hi Team,
>
> I would like to know, whether in IS-IS, a system id can be ..
> or it is an invalid value for sys I'd ?
>
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
> mention explicitly whether SYS ID of .. could be invalid.
>
> Also as per RFC 3784, it says System id is typically of 6 bytes, but
> doesn't talk about any invalid option.
>
> The reason I am asking this is that Juniper defines a SYS ID of
> .. as invalid.
>
>
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>
>
> This can cause issues in inter-operability as some vendors like Cisco
> doesn't define a SYS-ID of .. as invalid.
>
> I would appreciate your response on this.
>
> Regards
>
> Jaideep Choudhary
>
> On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT, 
> wrote:
>
>> Hi Jaideep,
>>
>> You have reached the IETF Secretariat, which is the administrative branch
>> of the IETF, and as such, we are not qualified to answer your technical
>> questions.
>>
>> You might have better luck if you try posing your question to the Link
>> State Routing (LSR) Working Group (
>> https://datatracker.ietf.org/wg/lsr/about/). LSR was formed by merging
>> the ISIS and OSPF WGs and assigning all their existing adopted work at the
>> time of chartering to LSR. Their mailing list address is lsr@ietf.org.
>>
>> Best regards,
>> Cindy
>>
>> On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com wrote:
>>
>> Hi Team,
>>
>>
>> I would like to know, whether in IS-IS, a system id can be ..
>> or it is an invalid value for sys I'd ?
>>
>>
>> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
>> mention explicitly whether SYS ID of .. could be invalid.
>>
>>
>> Also as per RFC 3784, it says System id is typically of 6 bytes, but
>> doesn't talk about any invalid option.
>>
>>
>> The reason I am asking this is that Juniper defines a SYS ID of
>> .. as invalid.
>>
>>
>>
>>
>> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>>
>>
>> This can cause issues in inter-operability as some vendors like Cisco
>> doesn't define a SYS-ID of .. as invalid.
>>
>>
>> I would appreciate your response on this.
>>
>>
>> Regards
>>
>> Jaideep Choudhary
>>
>>
>>
>>
>> ___
> 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] [rt5.ietf.org #7080] System ID in ISIS

[Tony Li]

Hi,

Neither of these mailing lists are appropriate for technical support.  Please 
contact your vendors directly.

Tony


> On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary 
>  wrote:
> 
> Hi Team,
> I would like to know, whether in IS-IS, a system id can be .. or 
> it is an invalid value for sys I'd ?
> 
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
> explicitly whether SYS ID of .. could be invalid.
> 
> Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
> talk about any invalid option.
> 
> The reason I am asking this is that Juniper defines a SYS ID of 
> .. as invalid.
> 
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>  
> 
> 
> This can cause issues in inter-operability as some vendors like Cisco doesn't 
> define a SYS-ID of .. as invalid.
> 
> I would appreciate your response on this.
> 
> Regards
> 
> Jaideep Choudhary
> 
> 
> On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT,  > wrote:
> Hi Jaideep,
> 
> You have reached the IETF Secretariat, which is the administrative branch of 
> the IETF, and as such, we are not qualified to answer your technical 
> questions.
> 
> You might have better luck if you try posing your question to the Link State 
> Routing (LSR) Working Group (https://datatracker.ietf.org/wg/lsr/about/ 
> ). LSR was formed by merging the 
> ISIS and OSPF WGs and assigning all their existing adopted work at the time 
> of chartering to LSR. Their mailing list address is lsr@ietf.org 
> .
> 
> Best regards,
> Cindy
> 
> On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com 
>  wrote:
> 
> Hi Team,
>  
> I would like to know, whether in IS-IS, a system id can be .. or 
> it is an invalid value for sys I'd ?
> 
>  
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
> explicitly whether SYS ID of .. could be invalid.
> 
>  
> Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
> talk about any invalid option.
> 
>  
> The reason I am asking this is that Juniper defines a SYS ID of 
> .. as invalid.
> 
>  
>  
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>  
> 
>  
> This can cause issues in inter-operability as some vendors like Cisco doesn't 
> define a SYS-ID of .. as invalid.
> 
>  
> I would appreciate your response on this.
> 
>  
> Regards
> 
> Jaideep Choudhary
> 
>  
>  
>  
> ___
> 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] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John Scudder]

Hi Les and all,

> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> So you are suggesting that we publish something that was never actually 
> published as an RFC as a "historic RFC"?
> 
> The logic of that escapes me.

It so happens I recently became aware that this publication track is explicitly 
considered to be OK. 
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
 sez

"An RFC may be published directly as Historic, with no earlier status to change 
(see, for example, RFC 4870). This is usually done to document ideas that were 
considered and discarded, or protocols that were already historic when it was 
decided to document them. Those publications are handled as are any other RFCs.”

$0.02,

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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Robert Raszuk]

Acee,

> Note that any good implementation will allow one to punch holes in their
area ranges so that critical prefixes are advertised or

Every PE address is critical. The story that one PE can be more important
than any other is just to mislead you at best.

And we are (I hope) scoped the discussion to summaries.

I realize  PUE also wants to cover P failures so in this case each P is
also equally important.

Thx,
R,


On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Tuesday, June 14, 2022 at 9:27 AM
> *To: *Christian Hopps 
> *Cc: *Gunter Van de Velde , lsr <
> lsr@ietf.org>, "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" <
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>
> *Subject: *Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>
>
>
> All,
>
>
>
> > What is wrong with simply not doing summaries
>
>
>
> What's wrong is that you are reaching the scaling issue much sooner than
> when you inject summaries.
>
>
>
> Note that any good implementation will allow one to punch holes in their
> area ranges so that critical prefixes are advertised or included in the
> range existence criteria.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
> Note that the number of those host routes is flooded irrespective of the
> actual need everywhere based on the sick assumption that perhaps they may
> be needed there. There is no today to the best of my knowledge controlled
> leaking to only subset to what is needed.
>
>
>
> But this is not the main worry. Main worry is that in redundant networks
> you are seeing many copies of the very same route being flooded all over
> the place. So in a not so big 1000 node network the number of host routes
> may exceed 8000 easily. cri
>
>
>
> Sure when things are stable all is cool. But we should prepare for the
> worst, not the best. In fact, the ability to encapsulate to an aggregate
> switch IP (GRE or UDP) or nowadays SRv6 has been one of the strongest
> advantages.
>
>
>
> So as started before the problem does exist. Neither PULSE nor PUE solve
> it which are both limited to PE failures detection which is not enough
> (maybe even not worth). But PE-CE failures need to be signalled in the case
> of injecting summaries. Maybe as I said in previous msg just BGP withdrawal
> is fine. If not we should seek a solution which addresses the real problem,
> not an infrequent one.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
> On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps  wrote:
>
>
>
> > On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com> wrote:
> >
> > What is wrong with simply not doing summaries and forget about these
> PUAs to pinch holes in the summary prefixes? this worked very well during
> last two decennia. Are we not over-engineering with PUAs?
>
> 100% yes, IMO.
>
> Thanks,
> Chris.
> [as wg-member]
> ___
> 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] Thoughts about PUAs - are we not over-engineering?

[Acee Lindem (acee)]

Speaking as WG member:

From: Lsr  on behalf of Robert Raszuk 
Date: Tuesday, June 14, 2022 at 9:27 AM
To: Christian Hopps 
Cc: Gunter Van de Velde , lsr , 
"draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 
, 
draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

All,

> What is wrong with simply not doing summaries

What's wrong is that you are reaching the scaling issue much sooner than when 
you inject summaries.

Note that any good implementation will allow one to punch holes in their area 
ranges so that critical prefixes are advertised or included in the range 
existence criteria.

Thanks,
Acee


Note that the number of those host routes is flooded irrespective of the actual 
need everywhere based on the sick assumption that perhaps they may be needed 
there. There is no today to the best of my knowledge controlled leaking to only 
subset to what is needed.

But this is not the main worry. Main worry is that in redundant networks you 
are seeing many copies of the very same route being flooded all over the place. 
So in a not so big 1000 node network the number of host routes may exceed 8000 
easily. cri

Sure when things are stable all is cool. But we should prepare for the worst, 
not the best. In fact, the ability to encapsulate to an aggregate switch IP 
(GRE or UDP) or nowadays SRv6 has been one of the strongest advantages.

So as started before the problem does exist. Neither PULSE nor PUE solve it 
which are both limited to PE failures detection which is not enough (maybe even 
not worth). But PE-CE failures need to be signalled in the case of injecting 
summaries. Maybe as I said in previous msg just BGP withdrawal is fine. If not 
we should seek a solution which addresses the real problem, not an infrequent 
one.

Best,
R.



On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:


> On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) 
> mailto:gunter.van_de_ve...@nokia.com>> wrote:
>
> What is wrong with simply not doing summaries and forget about these PUAs to 
> pinch holes in the summary prefixes? this worked very well during last two 
> decennia. Are we not over-engineering with PUAs?

100% yes, IMO.

Thanks,
Chris.
[as wg-member]
___
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] Thoughts about PUAs - are we not over-engineering?

[Robert Raszuk]

All,

> What is wrong with simply not doing summaries

What's wrong is that you are reaching the scaling issue much sooner than
when you inject summaries.

Note that the number of those host routes is flooded irrespective of the
actual need everywhere based on the sick assumption that perhaps they may
be needed there. There is no today to the best of my knowledge controlled
leaking to only subset to what is needed.

But this is not the main worry. Main worry is that in redundant networks
you are seeing many copies of the very same route being flooded all over
the place. So in a not so big 1000 node network the number of host routes
may exceed 8000 easily.

Sure when things are stable all is cool. But we should prepare for the
worst, not the best. In fact, the ability to encapsulate to an aggregate
switch IP (GRE or UDP) or nowadays SRv6 has been one of the strongest
advantages.

So as started before the problem does exist. Neither PULSE nor PUE solve it
which are both limited to PE failures detection which is not enough (maybe
even not worth). But PE-CE failures need to be signalled in the case of
injecting summaries. Maybe as I said in previous msg just BGP withdrawal is
fine. If not we should seek a solution which addresses the real problem,
not an infrequent one.

Best,
R.



On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps  wrote:

>
>
> > On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com> wrote:
> >
> > What is wrong with simply not doing summaries and forget about these
> PUAs to pinch holes in the summary prefixes? this worked very well during
> last two decennia. Are we not over-engineering with PUAs?
>
> 100% yes, IMO.
>
> Thanks,
> Chris.
> [as wg-member]
> ___
> 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] [rt5.ietf.org #7080] System ID in ISIS

[Jaideep Choudhary]

Hi Team,

I would like to know, whether in IS-IS, a system id can be ..
or it is an invalid value for sys I'd ?

As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
mention explicitly whether SYS ID of .. could be invalid.

Also as per RFC 3784, it says System id is typically of 6 bytes, but
doesn't talk about any invalid option.

The reason I am asking this is that Juniper defines a SYS ID of
.. as invalid.

https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html


This can cause issues in inter-operability as some vendors like Cisco
doesn't define a SYS-ID of .. as invalid.

I would appreciate your response on this.

Regards

Jaideep Choudhary

On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT, 
wrote:

> Hi Jaideep,
>
> You have reached the IETF Secretariat, which is the administrative branch
> of the IETF, and as such, we are not qualified to answer your technical
> questions.
>
> You might have better luck if you try posing your question to the Link
> State Routing (LSR) Working Group (
> https://datatracker.ietf.org/wg/lsr/about/). LSR was formed by merging
> the ISIS and OSPF WGs and assigning all their existing adopted work at the
> time of chartering to LSR. Their mailing list address is lsr@ietf.org.
>
> Best regards,
> Cindy
>
> On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com wrote:
>
> Hi Team,
>
>
>
> I would like to know, whether in IS-IS, a system id can be ..
> or it is an invalid value for sys I'd ?
>
>
>
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't
> mention explicitly whether SYS ID of .. could be invalid.
>
>
>
> Also as per RFC 3784, it says System id is typically of 6 bytes, but
> doesn't talk about any invalid option.
>
>
>
> The reason I am asking this is that Juniper defines a SYS ID of
> .. as invalid.
>
>
>
>
>
>
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>
>
>
> This can cause issues in inter-operability as some vendors like Cisco
> doesn't define a SYS-ID of .. as invalid.
>
>
>
> I would appreciate your response on this.
>
>
>
> Regards
>
> Jaideep Choudhary
>
>
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Christian Hopps]

> On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  wrote:
> 
> What is wrong with simply not doing summaries and forget about these PUAs to 
> pinch holes in the summary prefixes? this worked very well during last two 
> decennia. Are we not over-engineering with PUAs?

100% yes, IMO.

Thanks,
Chris.
[as wg-member]
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Acee Lindem (acee)]

If an experimental technology proves successful, it will be promoted to 
standards track. Two notable examples are GRE and PIM. 
BIER may be another that eventually become standards track.  

Thanks,
Acee

On 6/14/22, 8:41 AM, "Christian Hopps"  wrote:



> On Jun 13, 2022, at 14:29, Tony Li  wrote:
> 
>  It used to be that the path to publication was brief. We’ve now ossified 
to the point where a technology can go through an entire life-cycle before we 
act. 

Yes, but we also seemed to publish everything as Informational then too. :-D

Thanks,
Chris.

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Christian Hopps]

> On Jun 14, 2022, at 08:41, Christian Hopps  wrote:
> 
> 
> 
>> On Jun 13, 2022, at 14:29, Tony Li  wrote:
>> 
>> It used to be that the path to publication was brief. We’ve now ossified to 
>> the point where a technology can go through an entire life-cycle before we 
>> act. 
> 
> Yes, but we also seemed to publish everything as Informational then too. :-D

All kidding aside, this *is* one of the really enjoyable aspects of working on 
IS-IS over the years. I don't think it was so much the speed of the IETF, but 
the sheer feature velocity the protocol and the actual industry users allowed 
for. The people who actually deployed IS-IS in their networks were very clueful 
and often worked directly with the vendors on the implementation and 
deployments and they both attended IETF and participated in the isiswg.

It made for quick work, that.

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Christian Hopps]

> On Jun 13, 2022, at 14:29, Tony Li  wrote:
> 
>  It used to be that the path to publication was brief. We’ve now ossified to 
> the point where a technology can go through an entire life-cycle before we 
> act. 

Yes, but we also seemed to publish everything as Informational then too. :-D

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

Re: [Lsr] Convergence of Prefixes Unreachable Announcement Proposals

[Aijun Wang]

Hi, Peter:

If the prefix is still reachable via the summary address, no additional  action 
should be triggered. 
In conclusion, UPA just tell the receiver that the detailed prefix is missing, 
not the detailed prefix unreachable.

Aijun Wang
China Telecom

> On Jun 14, 2022, at 15:12, Peter Psenak  wrote:
> 
> Aijun,
> 
> 
>> On 14/06/2022 02:35, Aijun Wang wrote:
>> Hi,Peter:
>> Then the final effects of UPA are the followings:
>> 1) If the specified prefix exist, the receiver will delete it upon receiving 
>> the UPA message—-But the specified prefix may still be reachable via other 
>> summary address.
>> 2)If the specified prefix doesn’t exist, it depends on the local behavior of 
>> the receiver—-The specified prefix may still also be reachable via the 
>> summary address.
>> Wrt the any of the above situations, the problem described at the beginning 
>> of the draft isn’t solved, Right?
> 
> above statements are based on some assumptions which may not be necessary 
> correct.
> 
> The handling of the received UPA a local matter on the receiver. What you 
> want is to trigger BGP PIC for destinations that resolve over the unreachable 
> prefix. How that is done and if you need to delete anything from RIB is the 
> matter of the implementation and outside of the scope of the draft.
> 
> thanks,
> Peter
> 
> 
>> Aijun Wang
>> China Telecom
 On Jun 13, 2022, at 21:14, Peter Psenak  wrote:
>>> 
>>> Aijun,
>>> 
>>> 
 On 13/06/2022 15:08, Aijun Wang wrote:
 Hi, Peter:
 Here I want to ask you one question:
 If the specified detailed prefix doesn’t exist in the receiver’s route 
 table, what the receiver will do when it receives the UPA information of 
 this specified prefix?
>>> 
>>> it's up to the receiver to process UPA the way he wants. We are not 
>>> specifying any of that. It's a local behavior on the receiver.
>>> 
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
>>> 
 Aijun Wang
 China Telecom
>> On Jun 10, 2022, at 23:16, Peter Psenak  wrote:
> 
> Aijun,
> 
>> On 08/06/2022 13:22, Aijun Wang wrote:
>> Hi, Peter:
>> “MAX-Value” metric just indicates the associated prefix will be removed 
>> if it is installed previously, as the same function of premature aging.
>> If the prefix doesn’t exist previously on the receiving router, it will 
>> do nothing when it receives such “MAX-Value” metric advertisements.
>> Thus, it can avoid the misbehavior when receiving the unrecognized TLV 
>> that indicates explicitly the unreachable information, but itself only 
>> can’t be used to trigger the switchover of overlay service on the 
>> mentioned prefix(such LSA will be passed immediately, as described in 
>> RFC2328).
> 
> sorry, I don't understand the above. Advertising a prefix with LSInfinity 
> will cause the prefix to become unreachable.
> 
> 
>> In summary, UPA just told the receiver the detailed prefix is missed(but 
>> may still be reached via the summary address),but not the prefix is 
>> unreachable.
> 
> and why is that a problem?
> 
>> Combine current two information together can declare clearly the 
>> detailed prefix is unreachable and unsupported router will not have any 
>> misbehavior when they don’t understand the PUA information.
> 
> things as described in UPA draft are sufficient to make prefix 
> unreachable. There will be no misbehavior, as we are using existing 
> mechanism to do so.
> 
> thanks,
> Peter
> 
>> And, when all the routers be upgraded(which are all necessary for both 
>> proposals) to support the PUA information , the UPA information can be 
>> omitted.
>> Aijun Wang
>> China Telecom
 On Jun 7, 2022, at 23:59, Peter Psenak  wrote:
>>> 
>>> Aijun,
>>> 
 On 07/06/2022 17:31, Aijun Wang wrote:
 Hi, Peter:
 The differences between our proposals are just how to indicate the 
 PUA/UPA information along with the advertised prefixes. All other 
 mechanisms/procedures are the same, right?
 Then one simple way for the convergence is just the encoding: Let the 
 unreachable prefixes associated with “prefix originator”(with the 
 value set to NULL”) and also set its metrics to MAX-Value.
>>> 
>>> there is no need to introduce any new encoding. That the whole point of 
>>> the UPA draft. We use existing mechanism.
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
 Other parts can follow the current PUA drafts, which we have discussed 
 intensively in the list and I think you have no any objections.
 Anyway, to make the UPA mechanism take effect, you will also require 
 the router be upgraded. And the “Max-Value” solution doesn’t 
 necessarily indicate the prefix is lost. We should announce such 
 information explicitly.
 We can also discuss 

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Gunter:

Let me try to answer some of your concerns.

The reason that we prefer to the Summary+PUA/UPA solution is that the node 
failure(which is the main scenario that we focus now) is one rarely thing in 
the network. Then the unreachable event triggered mechanism is more efficient 
than advertising all of the node’s reachable address. This point has been 
discussed in the mail list in past.

In the 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-8,
 we have illustrated how to control the advertisement of PUA message on the 
ABR. If this can’t settle your concerns, we can consider more policy on the ABR.

Regarding to the tracking and representation of PUA in RTM, we have proposed in 
the earlier version of this draft, that is to install one black hole route to 
the specified detailed prefix.

The reason that PUA requires routers within one area to be upgraded is that it 
want to avoid the situations when the router doesn’t recognize PUA message and 
misbehave. We are considering the convergence of PUA/UPA solutions, which may 
relax such requirements during deployment.


Aijun Wang
China Telecom

> On Jun 14, 2022, at 16:59, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  wrote:
> Hi All,
> 
> When reading both proposals about PUA's:
> * draft-ppsenak-lsr-igp-ureach-prefix-announce-00
> * draft-wang-lsr-prefix-unreachable-annoucement-09
> 
> The identified problem space seems a correct observation, and indeed 
> summaries hide remote area network instabilities. It is one of the perceived 
> benefits of using summaries. The place in the network where this hiding takes 
> the most impact upon convergence is at service nodes (PE's for 
> L3/L2/transport) where due to the summarization its difficult to detect that 
> the transport tunnel end-point suddenly becomes unreachable. My concern 
> however is if it really is a problem that is worthy for LSR WG to solve.
> 
> To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a 
> preferred solution due to the expectation that all nodes in an area must be 
> upgraded to support the IGP capability. From this operational perspective the 
> draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
> only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do 
> have concerns about the number of PUA advertisements in hierarchically 
> summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More 
> specific, in the /16 backbone area, how many of these PUAs will be floating 
> around creating LSP LSDB update churns? How to control the potentially 
> exponential number of observed PUAs from floating everywhere? (will this lead 
> to OSPF type NSSA areas where areas will be purged from these PUAs for 
> scaling stability?)
> 
> Long story short, should we not take a step back and re-think this identified 
> problem space? Is the proposed solution space not more evil as the problem 
> space? We do summarization because it brings stability and reduce the number 
> of link state updates within an area. And now with PUA we re-introduce 
> additional link state updates (PUAs), we blow up the LSDB with information 
> opaque to SPF best-path calculation. In addition there is suggestion of new 
> state-machinery to track the igp reachability of 'protected' prefixes and 
> there is maybe desire to contain or filter updates cross inter-area 
> boundaries. And finally, how will we represent and track PUA in the RTM?
> 
> What is wrong with simply not doing summaries and forget about these PUAs to 
> pinch holes in the summary prefixes? this worked very well during last two 
> decennia. Are we not over-engineering with PUAs?
> 
> G/
> 
> ___
> 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] Thoughts about PUAs - are we not over-engineering?

[Robert Raszuk]

Hello Gunter,

I agree with pretty much all you said except the conclusion - do nothing
:).

To me if you need to accelerate connectivity restoration upon an unlikely
event like a complete PE failure the right vehicle to signal this is
within the service layer itself. Let's keep in mind that links do fail a
lot in the networks - routers do not (or they do it is multiple orders of
magnitude less frequent event). Especially links on the PE-CE boundaries do
fail a lot.

Removal of next hop reachability can be done with BGP and based on BGP
native recursion will have the exact same effect as presented ideas.
Moreover it will be stateful for the endpoints which again to me is a
feature not a bug.

Some suggested to define a new extension in BGP to signal it even without
using double recursion - well one of them has been proposed in the past -
https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt At that
time the feedback received was that native BGP withdraws are fast enough so
no need to bother. Well those native withdrawals are working today as well
as some claim that specific implementations can withdraw RD:* when PE
hosting such RDs fail and RDs are allocated in a unique per VRF fashion.

Then we have the DROID proposal which again may look like overkill for this
very problem, but if you consider the bigger picture of what networks
control plane pub-sub signalling needs, it establishes the foundation for
such.

Many thanks,
Robert


On Tue, Jun 14, 2022 at 10:59 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <
gunter.van_de_ve...@nokia.com> wrote:

> Hi All,
>
> When reading both proposals about PUA's:
> * draft-ppsenak-lsr-igp-ureach-prefix-announce-00
> * draft-wang-lsr-prefix-unreachable-annoucement-09
>
> The identified problem space seems a correct observation, and indeed
> summaries hide remote area network instabilities. It is one of the
> perceived benefits of using summaries. The place in the network where this
> hiding takes the most impact upon convergence is at service nodes (PE's for
> L3/L2/transport) where due to the summarization its difficult to detect
> that the transport tunnel end-point suddenly becomes unreachable. My
> concern however is if it really is a problem that is worthy for LSR WG to
> solve.
>
> To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not
> a preferred solution due to the expectation that all nodes in an area must
> be upgraded to support the IGP capability. From this operational
> perspective the draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is
> more elegant, as only the A(S)BR's and particular PEs must be upgraded to
> support PUA's. I do have concerns about the number of PUA advertisements in
> hierarchically summarized networks (/24 (site) -> /20 (region) -> /16
> (core)). More specific, in the /16 backbone area, how many of these PUAs
> will be floating around creating LSP LSDB update churns? How to control the
> potentially exponential number of observed PUAs from floating everywhere?
> (will this lead to OSPF type NSSA areas where areas will be purged from
> these PUAs for scaling stability?)
>
> Long story short, should we not take a step back and re-think this
> identified problem space? Is the proposed solution space not more evil as
> the problem space? We do summarization because it brings stability and
> reduce the number of link state updates within an area. And now with PUA we
> re-introduce additional link state updates (PUAs), we blow up the LSDB with
> information opaque to SPF best-path calculation. In addition there is
> suggestion of new state-machinery to track the igp reachability of
> 'protected' prefixes and there is maybe desire to contain or filter updates
> cross inter-area boundaries. And finally, how will we represent and track
> PUA in the RTM?
>
> What is wrong with simply not doing summaries and forget about these PUAs
> to pinch holes in the summary prefixes? this worked very well during last
> two decennia. Are we not over-engineering with PUAs?
>
> G/
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Thoughts about PUAs - are we not over-engineering?

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed summaries 
hide remote area network instabilities. It is one of the perceived benefits of 
using summaries. The place in the network where this hiding takes the most 
impact upon convergence is at service nodes (PE's for L3/L2/transport) where 
due to the summarization its difficult to detect that the transport tunnel 
end-point suddenly becomes unreachable. My concern however is if it really is a 
problem that is worthy for LSR WG to solve.

To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a 
preferred solution due to the expectation that all nodes in an area must be 
upgraded to support the IGP capability. From this operational perspective the 
draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do 
have concerns about the number of PUA advertisements in hierarchically 
summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More specific, 
in the /16 backbone area, how many of these PUAs will be floating around 
creating LSP LSDB update churns? How to control the potentially exponential 
number of observed PUAs from floating everywhere? (will this lead to OSPF type 
NSSA areas where areas will be purged from these PUAs for scaling stability?)

Long story short, should we not take a step back and re-think this identified 
problem space? Is the proposed solution space not more evil as the problem 
space? We do summarization because it brings stability and reduce the number of 
link state updates within an area. And now with PUA we re-introduce additional 
link state updates (PUAs), we blow up the LSDB with information opaque to SPF 
best-path calculation. In addition there is suggestion of new state-machinery 
to track the igp reachability of 'protected' prefixes and there is maybe desire 
to contain or filter updates cross inter-area boundaries. And finally, how will 
we represent and track PUA in the RTM?

What is wrong with simply not doing summaries and forget about these PUAs to 
pinch holes in the summary prefixes? this worked very well during last two 
decennia. Are we not over-engineering with PUAs?

G/

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

Re: [Lsr] Convergence of Prefixes Unreachable Announcement Proposals

[Peter Psenak]

Aijun,


On 14/06/2022 02:35, Aijun Wang wrote:

Hi,Peter:
Then the final effects of UPA are the followings:
1) If the specified prefix exist, the receiver will delete it upon receiving 
the UPA message—-But the specified prefix may still be reachable via other 
summary address.
2)If the specified prefix doesn’t exist, it depends on the local behavior of 
the receiver—-The specified prefix may still also be reachable via the summary 
address.
Wrt the any of the above situations, the problem described at the beginning of 
the draft isn’t solved, Right?


above statements are based on some assumptions which may not be 
necessary correct.


The handling of the received UPA a local matter on the receiver. What 
you want is to trigger BGP PIC for destinations that resolve over the 
unreachable prefix. How that is done and if you need to delete anything 
from RIB is the matter of the implementation and outside of the scope of 
the draft.


thanks,
Peter





Aijun Wang
China Telecom


On Jun 13, 2022, at 21:14, Peter Psenak  wrote:

Aijun,



On 13/06/2022 15:08, Aijun Wang wrote:
Hi, Peter:
Here I want to ask you one question:
If the specified detailed prefix doesn’t exist in the receiver’s route table, 
what the receiver will do when it receives the UPA information of this 
specified prefix?


it's up to the receiver to process UPA the way he wants. We are not specifying 
any of that. It's a local behavior on the receiver.


thanks,
Peter




Aijun Wang
China Telecom

On Jun 10, 2022, at 23:16, Peter Psenak  wrote:


Aijun,


On 08/06/2022 13:22, Aijun Wang wrote:
Hi, Peter:
“MAX-Value” metric just indicates the associated prefix will be removed if it 
is installed previously, as the same function of premature aging.
If the prefix doesn’t exist previously on the receiving router, it will do 
nothing when it receives such “MAX-Value” metric advertisements.
Thus, it can avoid the misbehavior when receiving the unrecognized TLV that 
indicates explicitly the unreachable information, but itself only can’t be used 
to trigger the switchover of overlay service on the mentioned prefix(such LSA 
will be passed immediately, as described in RFC2328).


sorry, I don't understand the above. Advertising a prefix with LSInfinity will 
cause the prefix to become unreachable.



In summary, UPA just told the receiver the detailed prefix is missed(but may 
still be reached via the summary address),but not the prefix is unreachable.


and why is that a problem?


Combine current two information together can declare clearly the detailed 
prefix is unreachable and unsupported router will not have any misbehavior when 
they don’t understand the PUA information.


things as described in UPA draft are sufficient to make prefix unreachable. 
There will be no misbehavior, as we are using existing mechanism to do so.

thanks,
Peter


And, when all the routers be upgraded(which are all necessary for both 
proposals) to support the PUA information , the UPA information can be omitted.
Aijun Wang
China Telecom

On Jun 7, 2022, at 23:59, Peter Psenak  wrote:


Aijun,


On 07/06/2022 17:31, Aijun Wang wrote:
Hi, Peter:
The differences between our proposals are just how to indicate the PUA/UPA 
information along with the advertised prefixes. All other mechanisms/procedures 
are the same, right?
Then one simple way for the convergence is just the encoding: Let the 
unreachable prefixes associated with “prefix originator”(with the value set to 
NULL”) and also set its metrics to MAX-Value.


there is no need to introduce any new encoding. That the whole point of the UPA 
draft. We use existing mechanism.

thanks,
Peter



Other parts can follow the current PUA drafts, which we have discussed 
intensively in the list and I think you have no any objections.
Anyway, to make the UPA mechanism take effect, you will also require the router 
be upgraded. And the “Max-Value” solution doesn’t necessarily indicate the 
prefix is lost. We should announce such information explicitly.
We can also discuss other convergence solutions.
Aijun Wang
China Telecom

On Jun 7, 2022, at 20:34, Peter Psenak  wrote:


Hi Aijun,

thanks for your interest in the UPA draft.

I'm not sure what exactly is there in your draft that you would like to merge. 
The mechanism that we use in the UPA draft is an existing mechanism and it 
avoids the the problems that have been discussed in context of your draft in 
the past completely.

thanks,
Peter




On 07/06/2022 08:59, Aijun Wang wrote:
Hi, Authors of UPA(Unreachable Prefixes Announcement) draft:
After reading your newly proposed draft 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/ 
, we 
found that the overall aim and procedures in your draft are getting closer again to the 
already intensely discussed PUA/PUAM 
solutions(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09