Looks OK to me, aside from netconf’s typical non-best-practice use of XML
namespace prefixes in element content; but anything used to processing YANG
and friends will already need to have this capability.
On Jan 11, 2024 at 4:49:25 PM, David Dong via RT <
drafts-expert-review-comm...@iana.org>
Dear Tim and Martin (cc: lsr WG),
As the designated experts for the ns registry, can you review the proposed
registration in draft-ietf-lsr-ospfv3-extended-lsa-yang-25 for us? Please see:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
The due date is January 25.
If
The following errata report has been rejected for RFC5340,
"OSPF for IPv6".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7649
--
Status: Rejected
Type: Technical
Reported by: Owen DeLong
The following errata report has been rejected for RFC5838,
"Support of Address Families in OSPFv3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7644
--
Status: Rejected
Type: Technical
Hi Everyone,
I read through the document and support moving it forward.
Best Regards,
Huaimo
-Original Message-
From: Lsr On Behalf Of Acee Lindem
Sent: Monday, January 8, 2024 5:50 PM
To: Lsr
Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS
Multi-Topology (MT)
Hi John,
I now recall this discussion. In the context of OSPFv3, an OSPFv3 adjacency
over a tunnel should NOT be misconstrued as an OSPFv3 virtual link and the
Errata is invalid.
Thanks,
Acee
> On Jan 11, 2024, at 14:30, John Scudder wrote:
>
> Quickly reversing myself, and to quote my
Quickly reversing myself, and to quote my other reply just now: "Actually, upon
reviewing this one, I'm leaning back toward simply rejecting both this erratum
and erratum 7644. As we discussed earlier in the thread on this one, the best
fix (assuming the working group agrees is a fix is
Actually, upon reviewing this one, I'm leaning back toward simply rejecting
both this erratum and erratum 7644. As we discussed earlier in the thread on
this one, the best fix (assuming the working group agrees is a fix is merited,
of course) is a draft to update or replace the base spec.
Hi Acee, WG,
I'm convinced this doesn't meet the criteria to be verified as a technical
erratum. I am considering verifying it as "Hold for Document Update”, though.
The definition for HFDU is "The erratum is not a necessary update to the RFC.
However, any future update of the document might
The following errata report has been verified for RFC2328,
"OSPF Version 2".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7756
--
Status: Verified
Type: Editorial
Reported by: Lokesh
The following errata report has been rejected for RFC2328,
"OSPF Version 2".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7757
--
Status: Rejected
Type: Technical
Reported by: Lokesh
Now please refer to the original text in the RFC. It says"If the Forwarding
address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's
originator"Where the meaning is conveying wrong. On Fri,12 Jan 2024
06:22:42 +0530 acee.i...@gmail.com wrote Yes
> On Jan
Yes
> On Jan 11, 2024, at 11:28 AM, Lokesh Chakka wrote:
>
> So if forwarding address is 0.0.0.0, traffic will be directed towards the LSA
> originator.
> Otherwise it will be directed towards the LPM referred by forwarding address.
>
> Would like to understand if you agree or not.
>
>
>
So if forwarding address is 0.0.0.0, traffic will be directed towards the LSA
originator.Otherwise it will be directed towards the LPM referred by forwarding
address.Would like to understand if you agree or not. On Fri,12 Jan
2024 05:48:48 +0530 acee.i...@gmail.com wrote
> On
> On Jan 11, 2024, at 11:15 AM, Lokesh Chakka wrote:
>
> Can you please give me an example of routable Address
An address to which you can forward traffic based on the LPM in the IP route
table. A Router ID may be routable but it need not be.
I think we’re done now.
Acee
>
>
>
Can you please give me an example of routable Address On Fri,12 Jan
2024 05:40:55 +0530 acee.i...@gmail.com wrote
> On Jan 11, 2024, at 11:03 AM, lok...@truetraffik.in
> wrote:
>
> This is a valid Errata. Routable Address is nothing but a Router ID.
It's funny that you would
This Errata should be accepted.
Thanks,
Acee
> On Jan 11, 2024, at 12:41 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --
> You may review the report below and at:
>
> On Jan 11, 2024, at 11:03 AM, lok...@truetraffik.in
> wrote:
>
> This is a valid Errata. Routable Address is nothing but a Router ID.
It's funny that you would debate me on this point. If you make this assumption,
you should open an Errata on your implementation.
Excerpted from RFC
This is a valid Errata. Routable Address is nothing but a Router
ID.Thanks.Lokesh. On Fri,12 Jan 2024 05:30:08 +0530 acee.i...@gmail.com
wrote This Errata is invalid. The forwarding address contains a routable
address on the LSA originator or 0.0.0.0 - not a Router ID address.
This Errata is invalid. The forwarding address contains a routable address on
the LSA originator or 0.0.0.0 - not a Router ID address.
Thanks,
Acee
> On Jan 11, 2024, at 01:42, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Model for OSPFv3 Extended LSAs'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
Hi All,
I support the WGLC of the draft as the co-author. After several rounds of
refining, the draft is stable and well-written. It is the time for WGLC.
Best Regards,
Zhenbin (Robin)
-邮件原件-
发件人: Lsr 代表 Acee Lindem
发送时间: 2024年1月9日 6:50
收件人: Lsr
主题: [Lsr] Working Group Last Call for
Hi WG,
I support the publication of this document. I think this is a reasonable method
of network slicing implementation which could reuse the existing mechanism.
Some editing comments for authors' reference.
Best
Xuesong
--
1. Introduction
...
This document describes a
simplified
By it nature MT is a good candiate for the control plane of NRP, and it is
beneficial to reuse existing technology when applicable. The document has
limited its scope to providing a small number of NRPs, which can still be
useful for some networks.
I support the publication of this document.
Hi Les
The TEAS network slicing draft is the architectural framework draft for
IETF Network slicing.
What is meant by “IETF Network Slicing” is that any IETF technology such as
IGP MT or Flex Algo can be used to build a IETF Network slice Network
Resource partition (NRP).
I support publication.
IETF Network slicing can use any IETF technology such as ISIS MT to build
the network slice NRP.
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-25
This document describes network slicing in the context of networks built
from IETF technologies.
Hi all,
I support the last call of this document.
This document proposes a solution to build SR based NRPs by using
IS-IS MT, which maximizes the reuse of existing mechanisms. Since the idea is
good and the technical contents of this document is basically stable, I think
it can go
27 matches
Mail list logo
