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
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
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
> 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
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
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...)
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
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
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
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
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)
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
> 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?
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
> 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
> 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
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
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
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
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
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
35 matches
Mail list logo
