Hi Acee,
I am not aware of any IPR for this document other than the one already
reported.
Thanks,
Ketan
On Fri, 29 Jul, 2022, 10:48 pm Acee Lindem (acee), wrote:
> Co-authors,
>
>
>
> Are you aware of any IPR that applies to
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?
>
>
>
> If so, has
No Announce: thanks, we agree
Well, given LSP flooding is unrelible as well it seems no better and no worse
if we RTX. The PSNP bits will be hanging there and I guess we have to put it on
a RTX mechanism or we rely on CSNP. Good comment.
Yes, the PSNPs are _in addition_ so yes, I agree also
Hi Peter:
Supplement to yesterday's online questions, If a node that does not support IP
Flexalgo, which has a default route, should the node process the IP Flexalgo
prefix as a UPA?
Thanks
Zhibo
___
Lsr mailing list
Lsr@ietf.org
Tony (and everyone) -
Following up on the brief discussion about this draft at today's WG meeting...
I withdraw the comment regarding having to announce use of the algorithm. After
rereading I agree this is not necessary.
Regarding my second comment about the use of PSNPs as a recovery
Co-authors,
Are you aware of any IPR that applies to
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as a document author or contributor please respond
to
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
extra week is to account for PIST (Post-IETF Stress Syndrome). The
corresponding IS-IS draft is already on the RFC Queue and there are
Co-authors,
Are you aware of any IPR that applies to
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as a document author or contributor please respond
to
As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
extra week is to account for PIST (Post-IETF Stress Syndrome). The
corresponding IS-IS draft is already on the RFC Queue and there are
I fully agree with Shraddha.
In fact Section 4 of the draft makes clear why no protocol extensions are
needed.
Les
From: Lsr On Behalf Of Shraddha Hegde
Sent: Friday, July 29, 2022 2:18 AM
To: lsr@ietf.org
Subject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo
Authors,
I
On 29/07/2022 08:35, Aijun Wang wrote:
Hi, Peter:
I think you and all the subscribers of the LSR mail list have noticed not only
Zhibo express the opinions that LSInfinity cannot be used to indicate the
prefix is unreachable. There should exist other explicit indication.
Should we stop arguing
Hi, Peter:
I think you and all the subscribers of the LSR mail list have noticed not only
Zhibo express the opinions that LSInfinity cannot be used to indicate the
prefix is unreachable. There should exist other explicit indication.
Should we stop arguing this point then?
Aijun Wang
China
Zhibo,
On 28/07/2022 22:07, Huzhibo wrote:
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)
;
Hi, Robert:
I think your proposal are valid.
Option C like deployment can also use such information to select the optimized
inter-AS link to reach the routers in other domain.
The final effect will be like the EPE scenario.
Aijun Wang
China Telecom
> On Jul 29, 2022, at 16:44, Robert Raszuk
Authors,
I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don't see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older
>It only mandates that this prefix not be used in SPF computation, and leave
>the possibility of using it for other purposes,
>where "indicating the prefix is unreachable" could be one of the possible use
>cases
I totally agree with that statement.
An indication of unreachability in the
Hi Aijun,
How does this proposal impacts BGP path selection ?
Note that it is common to do next hop self on the ASBRs towards the
intradomain. So your proposal would not require any signalling to be
effective on a given ASBR. Local decision.
Originally I was under impression that you want to
16 matches
Mail list logo
