Hi, Acee:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee
Lindem
发送时间: 2024年1月16日 6:44
收件人: Aijun Wang
抄送: Christian Hopps ; Liyan Gong
; Yingzhen Qu ; lsr
; lsr-chairs
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024
-
Speaking as WG member:
Hi Aijun,
I know you have gotten some of your co-authors on other drafts and colleagues
to parrot your arguments in favor of this draft. However, you still have not
addressed my comments.
Why is better to advertise the link as stub link and surmise that it is an
Internet-Draft draft-ietf-lsr-ospfv3-extended-lsa-yang-26.txt is now
available. It is a work item of the Link State Routing (LSR) WG of the IETF.
Title: YANG Model for OSPFv3 Extended LSAs
Authors: Acee Lindem
Sharmila Palani
Yingzhen Qu
Name:
Hi Tom,
Since this YANG model describes the RFC 8362 encodings, those encodings should
be the primary reference all the leaves and identifies.
> On Jan 13, 2024, at 07:42, tom petch wrote:
>
> From: Lsr on behalf of The IESG
>
> Sent: 11 January 2024 14:35
>
> The IESG has received a
[As WG Co-chair]
I concur Chris's statement as WG co-chair.
The second adoption call should focus on the changes made since the first
one, and whether these changes addressed/fixed the issues raised during the
first adoption call.
Thanks,
Yingzhen
On Mon, Jan 15, 2024 at 8:15 AM Les Ginsberg
Hi,
As Les suggested in his email, below, I re-reviewed the first WG adoption
thread and the delta between the version proposed for the first WG adoption and
the version proposed for the second WG adoption, and I completely agree with
him that this is a gratuitous and ill-advised change to the
All,
The Errata is correct and should be accepted.
Thanks,
Acee
> On Jan 15, 2024, at 13:12, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC4576,
> "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in
> BGP/MPLS IP Virtual Private
The following errata report has been submitted for RFC4576,
"Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in
BGP/MPLS IP Virtual Private Networks (VPNs)".
--
You may review the report below and at:
From: Lsr on behalf of internet-dra...@ietf.org
Sent: 10 December 2023 03:37
Internet-Draft draft-ietf-lsr-ospf-prefix-extended-flags-00.txt is now
available. It is a work item of the Link State Routing (LSR) WG of the IETF.
Title: Prefix Flag Extension for OSPFv2 and OSPFv3
Authors:
I respect that individuals may have different opinions - but it is important to
distinguish what is factual from what is not.
Opinions based upon false information are clearly compromised.
Please do heed Chris's (as WG chair) admonition to review the first WG adoption
thread. That will reveal
Hi, Chris:
The first adoption call focus on the A.1 use case(figure 1), not cover all of
the use case that listed in A.1-A.3
For A.1(Figure 1) use case, previous discussions focus on mainly the benefits
of the configuration simplification, which you emphasize that IGP does not
mainly for such
> On Jan 15, 2024, at 06:27, Aijun Wang wrote:
>
> Hi, Chris：
>
> There are significant changes from the last adoption call(version 02) to the
> current version(version 08). Then I doubt the valid information from the
> previous discussions.
>
> For example, there is no concrete use cases
Hi, Chris：
There are significant changes from the last adoption call(version 02) to the
current version(version 08). Then I doubt the valid information from the
previous discussions.
For example, there is no concrete use cases description in the previous
version, which is provided in the
Liyan Gong writes:
Hi WG,
I Support its adoption.
Currently there is no automatic and error-proof way to get the
related information of the other ends for inter-as links, it is
difficult for operator to rebuild the complex inter-as topology.
The proposed protocol extension in this draft
"duzongp...@foxmail.com" writes:
Hi, all
I support the adoption. I agree with the idea:
Considering there are many links and complex interconnections
among the ASBRs that located in different AS domains, the proposed
protocol extension can certainly ease the recovery and management
Hi WG,
I Support its adoption.
Currently there is no automatic and error-proof way to get the related
information of the other ends for inter-as links, it is difficult for operator
to rebuild the complex inter-as topology.
The proposed protocol extension in this draft can assist the
Hi, all
I support the adoption. I agree with the idea:
Considering there are many links and complex interconnections among the
ASBRs that located in different AS domains, the proposed protocol extension can
certainly ease the recovery and management of inter-AS topologies.
Best Regards
17 matches
Mail list logo
