Hi authors, WG,
I also have some comments which aligns with Ketan’s first and third points as
below:
Firstly, both RFC 5305 and 5308 say that:
“If a prefix is advertised with a metric larger then MAX_PATH_METRIC (call it
infinite metric), this prefix MUST NOT be considered during the normal
Hi, Ketan:
In the inter-AS scenario, we will not deploy BGP session on each p2p link. The
BGP session exists only within the loopback address of each ASBR pair.
Such deployment is also same in the LAN scenario. Then there is no mesh or
partial p2p link that congruent to the BGP sessions.
Peter
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, July 29, 2022 8:33 AM
> To: Aijun Wang ; Acee Lindem (acee)
>
> Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
> ;
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr
Aijun,
On 28/07/2022 19:55, Aijun Wang wrote:
Hi, Acee:
Thanks for your comments, but most of them are indefensible, especially
the conclusion.
As you have also noticed, UPA mechanism doesn’t consider the network
partition scenarios, doesn’t consider how to control the number of
Hi, Acee:
Thanks for your comments, but most of them are indefensible, especially the
conclusion.
As you have also noticed, UPA mechanism doesn’t consider the network partition
scenarios, doesn’t consider how to control the number of advertisement of
unreachable messages, doesn’t provide
Hi Peter, Ketan,
See one inline.
On 7/28/22, 10:08 AM, "Lsr on behalf of Peter Psenak" wrote:
Hi Ketan,
On 28/07/2022 02:27, Ketan Talaulikar wrote:
> Hello Authors,
>
> Sharing some comments upfront on this draft given the packed LSR agenda.
>
> 1) There is
Hi Acee,
I agree with your so-called "baseless comments" on the differences between
the two drafts but I still hold some hope for further convergence between
the two proposals.
Thanks,
Ketan
On Thu, Jul 28, 2022 at 11:33 PM Acee Lindem (acee) wrote:
> Speaking as WG Member:
>
>
>
> Hi Ketan,
Speaking as WG Member:
Hi Ketan,
Thanks for pointing out the similarities. Even after the recent changes, there
are still some difference between the drafts which I’ll describe in the
baseless comments which follow. For conciseness, I’ll refer to the drafts as
PUA (Draft Wang) and UPA (Draft
Hi Ketan,
On 28/07/2022 02:27, Ketan Talaulikar wrote:
Hello Authors,
Sharing some comments upfront on this draft given the packed LSR agenda.
1) There is currently no change in protocol encoding (see also further
comment), however, there are protocol procedures at the ABR being
specified
Hi Aijun,
I am trying to summarize my understanding here just to make sure we are all
on the same page. There are also some suggestions on how we might be able
to make some progress here.
1) What "kind" of stub links is the draft proposing to address? (a)
Inter-AS links (this was the original
Hi Aijun,
Please check inline below.
On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang
wrote:
> Hi, Ketan:
>
> There are situation that such information is necessary:
> When several ASes are connected via the LAN interface, it is impossible to
> describe the inter-AS relationship with the current
Hi Aijun,
Please check inline below.
On Thu, Jul 28, 2022 at 1:09 PM Aijun Wang
wrote:
> Hi, Ketan:
>
> For the mentioned scenario, not only we need to run BGP-LS on every edge
> router, but also we need to configure every inter-AS link the following
> information: remote—AS number, remote
Hi, Ketan:
There are situation that such information is necessary:
When several ASes are connected via the LAN interface, it is impossible to
describe the inter-AS relationship with the current descriptors that provided
by RFC5316 and RFC5392.
And another scenario is that when these stub
Hi, Ketan:
For the mentioned scenario, not only we need to run BGP-LS on every edge
router, but also we need to configure every inter-AS link the following
information: remote—AS number, remote ASBR ID.
Regardless of the redundancy configured efforts, such information will be also
need to
Hi Aijun,
Similar to Les, I disagree with you on the use of Prefix TLV as an
attribute of the "Stub Link". The reason is that this attribute is not
required for the identification of a link in BGP-LS (or in IGPs for that
matter) that was the main use case. I also don't see the use of that in
Hi Acee,
Thanks for your clarifications and please check inline below for responses
as co-author of the referenced BGP-LS draft with Aijun.
On Thu, Jul 28, 2022 at 12:07 AM Acee Lindem (acee) wrote:
> Hi Ketan,
>
> I’m glad you brought this up. The primary (and AFAIK only) reason for this
>
Hi, Les:
Please note the references to RFC5316/RFC5392 in
draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what we
are discussing are non-TE scenarios.
For prefixes sub-TLV, would you like to revisit my responses to Ketan, before
make any comments? For your convenience, I
Hi Aijun,
Indeed, your draft has done a "pivot" in the latest version with the use of
LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to
move away from the use of Prefix Originator.
IMHO that would also bring the PUA and UPA proposals much closer to each
other.
Thanks,
Hello Authors,
Sharing some comments upfront on this draft given the packed LSR agenda.
1) There is currently no change in protocol encoding (see also further
comment), however, there are protocol procedures at the ABR being specified
using normative language. Specifically, the text related to
19 matches
Mail list logo
