Chongfeng –
We are at the stage of last call.
The document has been presented and discussed previously – it is time for WG
members to render their opinions.
For folks who have actively followed/participated in the discussion, it is very
unlikely that we will alter opinions by further
Hi all,
I support the adoption of this draft.
This solution is useful for the transmission of the information
of stub link, which enables BGP-LS to not only collect the topology information
of individual ASes, but also collect the connection information between
different ASes. And this
The following errata report has been submitted for RFC2328,
"OSPF Version 2".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7757
--
Type: Technical
Reported by: Lokesh Venkata Kumar Chakka
Hi,
Support, I've read this document and support its publication. It is
reasonable to reuse MT for NRPs to meet the requirements in some network
scenarios.
Best regard
Guoqi
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2024年1月9日 06:50
收件人: Lsr
主题: [Lsr]
The following errata report has been submitted for RFC2328,
"OSPF Version 2".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7756
--
Type: Editorial
Reported by: Lokesh Venkata Kumar Chakka
Hi Les,
Thanks for your comments.
This is an informational document which describes the applicability of existing
IS-IS MT mechanisms for building SR based NRPs. All the normative references
are either RFCs or stable WG documents. It is true that some informative
references are individual
Hi All,
No, I'm not aware of any IPR regarding this document.
Best regards,
Zhenbin (Robin)
-邮件原件-
发件人: Acee Lindem
发送时间: 2024年1月9日 6:43
收件人: draft-ietf-lsr-isis-sr-vtn...@ietf.org
抄送: Lsr
主题: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT)
for Segment
Hi Joel,
Thanks for your comments. It is good to know you also think using MT to support
NRP is a good idea.
Regarding the timing of the last call, the enhanced VPN framework draft has
finished the WG LC in TEAS WG, and this document has been stable for quite a
while, thus it seems now is
Hi, Chris:
For the use case A.1(inter-as topology recovery), RFC9346/RFC5392 based
solution requires the prerequisite knowledge of remote identifier on each stub
link. Considering there maybe tens/hundreds of links among the ASBRs, there is
no easy way to get such information automatically
Hi John,
Thanks for the review. I've published version -25 to address your comments.
Details below inline.
Thanks,
Yingzhen
On Wed, Jan 10, 2024 at 11:07 AM John Scudder wrote:
> Hi All,
>
> Thanks for the easy review, basically LGTM. I have just a few nits, below.
> I'll hold off on sending
Internet-Draft draft-ietf-lsr-ospfv3-extended-lsa-yang-25.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:
(NOTE: I am replying to Joel’s post rather than the original last call email
because I share some of Joel’s concerns – though my opinion on the merits of
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)
I oppose Last Call for
Given that the documents that provide the basic definitions needed for
this are still active Internet Drafts, it seems premature to last call
this document.
As a lesser matter, it seems odd that
draft-ietf-teas-ietf-network-slices, which defines the terms needed to
understand this draft, is
Hi All,
Thanks for the easy review, basically LGTM. I have just a few nits, below. I'll
hold off on sending the doc for IETF LC for a short time, in case you want to
fix these first. (It would be OK to send the current version, but IMO you might
as well do another revision since GENART or
Hi Tom,
The ticket I opened is now fixed and a datatracker search for say, “ospf-“ will
display both RFCs and drafts (including RFC 8665 and RFC 8666). The datatracker
has seemingly gone through some major changes and instability but seems to work
well now.
Thanks,
Acee
> On Jan 10, 2024,
I commented last month that I thought that RFC8665 should be in the datatracker
pages for LSR WG; I was wrong.
I raised an issue and now understand that the date that counts is when the I-D
was submitted to the RFC Editor. For this I-D, that was before the OSPF WG was
wound up so that
[As WG Co-Chair]
Hi Folks,
Before posting support reasons please read and considerl
*all* the email in the archive covering the first failed
adoption call.
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
Hi Acee:
You're right, there are alternatives to address inter-domain link
advertisements, and this document attempts to address such issues in a more
simplified way, reducing the number of BGP-LS sessions required, or avoid the
configurations related to the peering AS domains as
18 matches
Mail list logo
