>
> no. It's a limit not a delay.
That is directly contradicting the message from Les stating that this is
going to be a rate limit not cut out.
*"[LES2:] It is reasonable to limit the rate of pulses sent. "*
If too many edge nodes loose connectivity
> to the ABR in its area, it's a result of
Hi Peter,
thank you for your response. I'm looking forward to the new version of the
draft. It will be interesting to learn the criteria that enable an ABR to
reliably identify the scenarios you've suggested are outside the scope of
the PULSE draft and should be handled differently.
Regards,
Greg
Hi Greg,
On 04/01/2022 18:13, Greg Mirsky wrote:
Hi Peter,
I'm probably missing something in the current PULSE but I cannot find
the mechanism that limits the number of the pulses. Do you envision that
being like a throttling mechanism? But delaying the propagation of
notification for some
Hi Peter,
I'm probably missing something in the current PULSE but I cannot find the
mechanism that limits the number of the pulses. Do you envision that being
like a throttling mechanism? But delaying the propagation of notification
for some events might cause more instability in a network.
The IESG has approved the following document:
- 'YANG Module for IS-IS Reverse Metric'
(draft-ietf-lsr-yang-isis-reverse-metric-06.txt) as Proposed Standard
This document is the product of the Link State Routing Working Group.
The IESG contact persons are Alvaro Retana, John Scudder and Martin
Hi Aijun,
In most deployments summary routes are already crafted carefully to only
cover those destinations which are important and should be reachable from
outside of the area.
So I see no point in building yet another policy to select a subset of
summaries to be PUA eligible.
Along those
I think the mentioned solution can also address Robert and Christian’s concerns.
Aijun Wang
China Telecom
> On Jan 5, 2022, at 07:02, Aijun Wang wrote:
>
> Hi, Greg:
>
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8
> has some description
Hi, Greg:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8
has some description for such considerations:
“ In order to reduce the unnecessary advertisements of PUAM
messages on ABRs, the ABRs should support the configuration of the
protected
Hi, Robert:
From: lsr-boun...@ietf.org On Behalf Of Robert Raszuk
Sent: Wednesday, January 5, 2022 7:55 AM
To: Aijun Wang
Cc: Greg Mirsky ; Les Ginsberg (ginsberg)
; Christian Hopps ; Shraddha Hegde
; Tony Li ; Hannes Gredler
; lsr ; Peter Psenak
Subject: Re: [Lsr] BGP vs PUA/PULSE
Hi Greg,
On 03/01/2022 23:17, Greg Mirsky wrote:
Happy New Year to All!
Hi Peter,
Top-pasting:
In 99,99% of cases there will be only single pulse generated when one PE
goes down. That itself is a very rare event itself.
We can easily limit the number of pulses generated on ABR to a single
Chris,
On 03/01/2022 20:23, Christian Hopps wrote:
Peter Psenak writes:
Chris,
On 03/01/2022 17:18, Christian Hopps wrote:
Peter Psenak writes:
On 03/01/2022 16:21, Christian Hopps wrote:
On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
wrote:
Tony –
Let me try one
Hi Robert,
On 03/01/2022 19:33, Robert Raszuk wrote:
Hi Peter,
Take SR-MPLS and RFC8667.
for MPLS summarization is practically not possible, we have been through
that.
Take RFC7810
TE metric is only advertised for links, not for prefixes.
Take RFC5120
I do not see any relevance
Peter,
> > Take SR-MPLS and RFC8667.
>
> for MPLS summarization is practically not possible, we have been through
> that.
>
The point is that the proposed solution is applicable to only a subset of
real practical deployments even if everyone would agree that this is a cool
idea.
> > Take
Hi, Christian:
In our concerned scenarios, it is not one or small part of the prefixes that is
important.
Instead, the loopback addresses of all PEs(for overlay BGP/BGP VPN services),
or all Ps(for SRv6 tunnel service) are all important.
Extract them out of the summary addresses and advertise
Hi, Christian and all:
The stub links are used in widespread within the network, and it is useful
to identify them within the IGP in several scenarios (as described in
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02
#section-1).
I support its adoption.
I am not
Robert,
On 04/01/2022 11:42, Robert Raszuk wrote:
Peter,
> Take SR-MPLS and RFC8667.
for MPLS summarization is practically not possible, we have been
through
that.
The point is that the proposed solution is applicable to only a subset
of real practical deployments even if
Hi Chris,
All good. Thanks for the updates and the confirmation.
Regards,
Rob
-Original Message-
From: iesg On Behalf Of Christian Hopps
Sent: 01 January 2022 09:25
To: Rob Wilton (rwilton)
Cc: draft-ietf-lsr-yang-isis-reverse-met...@ietf.org; lsr-cha...@ietf.org; The
IESG ;
Hi WG,
Support adoption.
Regards,
PSF
--原始邮件--
发件人：ChristianHopps
收件人：lsr@ietf.org;
抄送人：lsr-cha...@ietf.org;lsr-...@ietf.org;cho...@chopps.org;draft-wang-lsr-stub-link-attribu...@ietf.org;
日 期 ：2022年01月04日 15:04
主 题 ：[Lsr] WG Adoption Call for
I am not aware of any undisclosed IPR.
I support WG adoption.
Thanks
Gyan
On Tue, Jan 4, 2022 at 2:04 AM Christian Hopps wrote:
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>
> Please
"Aijun Wang" writes:
Hi, Christian:
In our concerned scenarios, it is not one or small part of the prefixes that is
important.
Instead, the loopback addresses of all PEs(for overlay BGP/BGP VPN services),
or all Ps(for SRv6 tunnel service) are all important.
Extract them out of the summary
20 matches
Mail list logo
