sr]
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
[External Email. Be cautious of content]
Robert,
On 09/03/2021 12:20, Robert Raszuk wrote:
> In addition you may have a hierarchical RR, which would still
involve > BGP signalling.
Last time I measur
draft-wang-lsr-prefix-unreachable-annoucement
Subject: Re: [Lsr]
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
I agree problem is valid for networks that use summarization and leaking for
inter-domain connectivity.
However, I don't think the solution space has to
://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
[External Email. Be cautious of content]
Robert,
On 09/03/2021 12:20, Robert Raszuk wrote:
>
> > In addition you may have a hierarchical RR, which would still
> involve > BGP signalling.
>
> Last time I m
Hi Gyan,
I guess you didn’t understand my first PUA question. See inline.
From: Gyan Mishra
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem
Cc: Aijun Wang ,
draft-wang-lsr-prefix-unreachable-annoucement
, lsr
Subject: Re:
same thing. if you want go multiple hops ZeroMQ you need forwarding
already. And if you go one hop it really doesn't matter, it's just FOSE
(flooding over something else ;-)
-- tony
On Wed, Mar 10, 2021 at 12:52 PM Robert Raszuk wrote:
> > You think Kafka here?
>
> Nope ... I meant ZeroMQ
> You think Kafka here?
Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
service related info.
Thx,
R.,
On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda
wrote:
> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
> that sort, it was basically KV
? Last time I looked @ it (and it's been a while) Open-R had nothing of
that sort, it was basically KV playing LSDB (innovative and clever in
itself). You think Kafka here? Which in turn needs underlying IGP however
and is nothing but BGP problems in new clothes having looked @ their
internal
Robert,
On 10/03/2021 11:29, Robert Raszuk wrote:
Peter,
> But suddenly the DOWN event distribution is considered
> problematic. Not sure I follow.
In routing and IP reachability we use p2mp distribution and flooding as
it is required to provide any to any connectivity.
Such spray model
Peter,
> But suddenly the DOWN event distribution is considered
> problematic. Not sure I follow.
In routing and IP reachability we use p2mp distribution and flooding as it
is required to provide any to any connectivity.
Such spray model no longer fits services where not every endpoint
Robert,
On 09/03/2021 19:30, Robert Raszuk wrote:
Hi Peter,
> Example 1:
>
> If session to PE1 goes down, withdraw all RDs received from such PE.
still dependent on RDs and BGP specific.
To me this does sound like a feature ... to you I think it was rather
pejorative.
Hi Peter,
> > Example 1:
> >
> > If session to PE1 goes down, withdraw all RDs received from such PE.
>
> still dependent on RDs and BGP specific.
To me this does sound like a feature ... to you I think it was rather
pejorative.
> We want app independent way of
> signaling the reachability
Robert,
On 09/03/2021 12:20, Robert Raszuk wrote:
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.
> because BGP signalling is prefix based and as a
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.
> because BGP signalling is prefix based and as a result slow.
+
> that is the whole point, you need something
I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
Hi Robert,
On 09/03/2021 12:02, Robert Raszuk wrote:
Hey Peter,
Well ok so let's forget about LDP - cool !
So IGP sends summary around and that is all what is needed.
So the question why not propage information that PE went down in service
signalling - today mainly BGP.
because BGP
Hey Peter,
Well ok so let's forget about LDP - cool !
So IGP sends summary around and that is all what is needed.
So the question why not propage information that PE went down in service
signalling - today mainly BGP.
> And forget BFD, does not scale with 10k PEs.
You missed the point. No
> You’re trying to fix a problem in the overlay by morphing the underlay.
How can that seem like a good idea?
I think this really nails this discussion.
We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
Tony,
On 09/03/2021 01:03, Tony Li wrote:
Gyan,
If I understand the purpose of this draft, the point is to punch a hole
in a summary so that traffic is redirected via an alternate, working path.
Rather than punch a hole, why not rely on existing technology? Have the
valid path advertise
Hi, Tony:
Aijun Wang
China Telecom
> On Mar 9, 2021, at 12:32, Tony Li wrote:
>
>
> Hi Aijun,
>
>> Stuffing things in the IGP seems like a poor way of determining that there’s
>> a BGP failure. Wouldn’t BFD be a more appropriate way of determining the
>> loss of connectivity? Or
Hi Tony,
On Mon, Mar 8, 2021 at 11:39 PM Tony Li wrote:
>
> Hi Gyan,
>
> > Gyan> In previous threads BFD multi hop has been mentioned to track
> IGP liveliness but that gets way overly complicated especially with large
> domains and not viable.
>
>
> This is not tracking IGP liveness, this
Hi Gyan,
> Gyan> In previous threads BFD multi hop has been mentioned to track IGP
> liveliness but that gets way overly complicated especially with large domains
> and not viable.
This is not tracking IGP liveness, this is to track BGP endpoint liveness.
Here in 2021, we seem to have
Hi Aijun,
> Stuffing things in the IGP seems like a poor way of determining that there’s
> a BGP failure. Wouldn’t BFD be a more appropriate way of determining the
> loss of connectivity? Or aggressive BGP keepalive timers?
> [WAJ] For BFD, you need to configure between each pair of them to
> Cc: lsr ; draft-wang-lsr-prefix-unreachable-annoucement <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>; Acee Lindem
> (acee) ; Aijun Wang ; Gyan
> Mishra
> Subject: Re: [Lsr]
> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
>
/draft-wang-lsr-prefix-unreachable-annoucement-05
Hi Aijun,
> [WAJ] We just want to avoid such silent discard behavior, especially for the
> scenario that there is BGP session run on such failure prefix.
Stuffing things in the IGP seems like a poor way of determining that there’s a
BGP f
Hi Aijun,
> [WAJ] We just want to avoid such silent discard behavior, especially for the
> scenario that there is BGP session run on such failure prefix.
Stuffing things in the IGP seems like a poor way of determining that there’s a
BGP failure. Wouldn’t BFD be a more appropriate way of
Hi, Acee:
Let me state my considerations for your questions.
Aijun Wang
China Telecom
> On Mar 9, 2021, at 08:37, Acee Lindem (acee) wrote:
>
>
> Speaking as a WG member:
>
> Hi Gyan,
>
> The first question is how do you know which prefixes within the summary range
> to protect? Are
On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) wrote:
> Speaking as a WG member:
>
>
>
> Hi Gyan,
>
>
>
> The first question is how do you know which prefixes within the summary
> range to protect? Are these configured? Is this half-assed best-effort
> protection where you protect prefixes
Hi, Tony:
Aijun Wang
China Telecom
> On Mar 9, 2021, at 08:22, Tony Li wrote:
>
>
> Hi Aijun,
>>
>> There are two scenarios as introduced by Gyan: one is the node
>> failure(Scenario 1), and another is the link failure(Scenario 2).
>>
>> For scenario 1, also when all ABRs can’t reach the
Hi Tony
On Mon, Mar 8, 2021 at 7:22 PM Tony Li wrote:
>
> Hi Aijun,
> >
> > There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
> >
> > For scenario 1, also when all ABRs can’t reach the specified address, it
> is
Speaking as a WG member:
Hi Gyan,
The first question is how do you know which prefixes within the summary range
to protect? Are these configured? Is this half-assed best-effort protection
where you protect prefixes within the range that you’ve installed recently?
Just how does this work? It
Hi Aijun,
>
> There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
>
> For scenario 1, also when all ABRs can’t reach the specified address, it is
> not efficient to advertise all of other detail prefixes when only
Hi, Tony:
There are two scenarios as introduced by Gyan: one is the node failure(Scenario
1), and another is the link failure(Scenario 2).
For scenario 1, also when all ABRs can’t reach the specified address, it is not
efficient to advertise all of other detail prefixes when only one prefix or
Gyan,
If I understand the purpose of this draft, the point is to punch a hole in a
summary so that traffic is redirected via an alternate, working path.
Rather than punch a hole, why not rely on existing technology? Have the valid
path advertise the more specific. This will attract the
Acee.
Please ask the two questions you raised about the PUA draft so we can
address your concerns.
If anyone else has any other outstanding questions or concerns we would
like to address as well and resolve.
Once all questions and concerns are satisfied we would like to ask for WG
adoption.
34 matches
Mail list logo
