Re: [Lsr] [IANA #1302946] expert review for draft-ietf-lsr-ospfv3-extended-lsa-yang (xml-registry)

[Tim Bray]

 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> wrote:

> 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 this is OK, when the IESG approves the document for publication, we'll
> make the registration at:
>
> https://www.iana.org/assignments/xml-registry/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the first
> response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [IANA #1302946] expert review for draft-ietf-lsr-ospfv3-extended-lsa-yang (xml-registry)

[David Dong via RT]

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 this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/xml-registry/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Errata Rejected] RFC5340 (7649)

[RFC Errata System]

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 
Date Reported: 2023-09-19
Rejected by: John Scudder (IESG)

Section: A.3.3 (in part)

Original Text
-
Interface MTU
  The size in bytes of the largest IPv6 datagram that can be sent
  out the associated interface without fragmentation.  The MTUs of
  common Internet link types can be found in Table 7-1 of [MTUDISC].
  Interface MTU should be set to 0 in Database Description packets
  sent over virtual links.


Corrected Text
--
Interface MTU
  The size in bytes of the largest IPv6 datagram that can be sent
  out the associated interface without fragmentation.  The MTUs of
  common Internet link types can be found in Table 7-1 of [MTUDISC].
  Interface MTU should be set to 0 in Database Description packets
  sent over OSPF virtual links. This rule should not be applied to tunnel
  or other software interfaces.

Notes
-
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and 
this provision makes sense. For interfaces that have an actual MTU, even though 
they may be "virtual" interfaces, they are not "virtual links" in the intended 
meaning of this paragraph. As such, this change will provide clarification and 
remove ambiguity from the current standard. At least one popular router vendor 
implements this RFC as MTU = 0 sent on all GRE interfaces which results in 
incompatibilities with most other router platforms which expect an actual 
value. The router vendor points to this provision in the RFCs as justification 
for their implementation. It is (arguably) a legitimate, if nonsensical 
interpretation of the existing text.
 --VERIFIER NOTES-- 
See discussion at 
https://mailarchive.ietf.org/arch/msg/lsr/mrmkQt9ETTYemukBzl6K_FmgHps/

It seems as though there is not clear consensus for the proposed change or even 
to make a similar change; as such the normal WG process (internet draft, WG 
consensus) is a better way to pursue the goal.

--
RFC5340 (draft-ietf-ospf-ospfv3-update-23)
--
Title   : OSPF for IPv6
Publication Date: July 2008
Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
Category: PROPOSED STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Errata Rejected] RFC5838 (7644)

[RFC Errata System]

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

Reported by: Owen DeLong 
Date Reported: 2023-09-17
Rejected by: John Scudder (IESG)

Section: 2.7

Original Text
-
   Interface MTU
  The size in octets of the largest address family specific datagram
  that can be sent on the associated interface without
  fragmentation.  The MTUs of common Internet link types can be
  found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
  to 0 in Database Description packets sent over virtual links.


Corrected Text
--
   Interface MTU
  The size in octets of the largest address family specific datagram
  that can be sent on the associated interface without
  fragmentation.  The MTUs of common Internet link types can be
  found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
  to 0 in Database Description packets sent over (OSPF3) virtual links.
  This recommendation MUST NOT be applied to tunnel and other virtual
  or software interfaces which carry traffic other than OSPF protocol 
packets.

Notes
-
Currently, the language is ambiguous and at least one vendor has implemented 
OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as 
IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of 
the RFC is to refer strictly to OSPF virtual-links which carry only OSPF 
protocol data and therefore have no meaningful MTU. When this is mistakenly 
applied to other forms of "virtual" interfaces such as tunnels, the results can 
be quite harmful.

As such, I think that clarification is in order, since the vendor in question 
is unrepentant and claims their current implementation to be compliant with the 
RFC.
 --VERIFIER NOTES-- 
   See discussion at 
https://mailarchive.ietf.org/arch/msg/lsr/wXdOtU9H2vIoA1xs10xZ4oh8bwU/

--
RFC5838 (draft-ietf-ospf-af-alt-10)
--
Title   : Support of Address Families in OSPFv3
Publication Date: April 2010
Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
Aggarwal
Category: PROPOSED STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Huaimo Chen]

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) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06

This begins a two week LSR Working Group last call for the "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)". Please express your support or objection prior to Tuesday, January 
23rd, 2024.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[Acee Lindem]

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 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 merited, of 
> course) is a draft to update or replace the base spec.”
> 
> In short, “never mind!”
> 
> —John
> 
>> On Jan 11, 2024, at 2:24 PM, John Scudder  wrote:
>> 
>> 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 consider this 
>> erratum, and determine whether it is correct and merits including in the 
>> update.” [1]
>> 
>> Please let me know soon if you have any concerns about that disposition.
>> 
>> --John
>> 
>> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
>> 
>> 
>>> On Sep 17, 2023, at 6:25 PM, Acee Lindem  wrote:
>>> 
>>> Given that the context of the “Interface MTU” is specifically the 
>>> “interface MTU” field in OSPFv3 Database Description packets and OSPF 
>>> virtual links (RFC 2328), the additions recommended in this Errata are 
>>> unnecessary. The Errata should be rejected.
>>> 
>>> Thanks,
>>> Acee
 On Sep 17, 2023, at 15:58, RFC Errata System  
 wrote:
 
 The following errata report has been submitted for RFC5838,
 "Support of Address Families in OSPFv3".
 
 --
 You may review the report below and at:
 https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
 
 --
 Type: Technical
 Reported by: Owen DeLong 
 
 Section: 2.7
 
 Original Text
 -
 Interface MTU
   The size in octets of the largest address family specific datagram
   that can be sent on the associated interface without
   fragmentation.  The MTUs of common Internet link types can be
   found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
   to 0 in Database Description packets sent over virtual links.
 
 
 Corrected Text
 --
 Interface MTU
   The size in octets of the largest address family specific datagram
   that can be sent on the associated interface without
   fragmentation.  The MTUs of common Internet link types can be
   found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
   to 0 in Database Description packets sent over (OSPF3) virtual links.
   This recommendation MUST NOT be applied to tunnel and other virtual
   or software interfaces which carry traffic other than OSPF protocol 
 packets.
 
 Notes
 -
 Currently, the language is ambiguous and at least one vendor has 
 implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly 
 others such as IPIP, IPSEC, etc., as I have not tested these). I believe 
 that the intent of the RFC is to refer strictly to OSPF virtual-links 
 which carry only OSPF protocol data and therefore have no meaningful MTU. 
 When this is mistakenly applied to other forms of "virtual" interfaces 
 such as tunnels, the results can be quite harmful.
 
 As such, I think that clarification is in order, since the vendor in 
 question is unrepentant and claims their current implementation to be 
 compliant with the RFC.
 
 Instructions:
 -
 This erratum is currently posted as "Reported". If necessary, please
 use "Reply All" to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party
 can log in to change the status and edit the report, if necessary.
 
 --
 RFC5838 (draft-ietf-ospf-af-alt-10)
 --
 Title   : Support of Address Families in OSPFv3
 Publication Date: April 2010
 Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
 Aggarwal
 Category: PROPOSED STANDARD
 Source  : Open Shortest Path First IGP
 Area: Routing
 Stream  : IETF
 Verifying Party : IESG
 
 ___
 Lsr mailing list
 Lsr@ietf.org
 

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[John Scudder]

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 merited, of course) is a 
draft to update or replace the base spec.”

In short, “never mind!”

—John

> On Jan 11, 2024, at 2:24 PM, John Scudder  wrote:
> 
> 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 consider this erratum, and 
> determine whether it is correct and merits including in the update.” [1]
> 
> Please let me know soon if you have any concerns about that disposition.
> 
> --John
> 
> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> 
>> On Sep 17, 2023, at 6:25 PM, Acee Lindem  wrote:
>> 
>> Given that the context of the “Interface MTU” is specifically the “interface 
>> MTU” field in OSPFv3 Database Description packets and OSPF virtual links 
>> (RFC 2328), the additions recommended in this Errata are unnecessary. The 
>> Errata should be rejected.
>> 
>> Thanks,
>> Acee
>>> On Sep 17, 2023, at 15:58, RFC Errata System  
>>> wrote:
>>> 
>>> The following errata report has been submitted for RFC5838,
>>> "Support of Address Families in OSPFv3".
>>> 
>>> --
>>> You may review the report below and at:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Owen DeLong 
>>> 
>>> Section: 2.7
>>> 
>>> Original Text
>>> -
>>> Interface MTU
>>>The size in octets of the largest address family specific datagram
>>>that can be sent on the associated interface without
>>>fragmentation.  The MTUs of common Internet link types can be
>>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>>>to 0 in Database Description packets sent over virtual links.
>>> 
>>> 
>>> Corrected Text
>>> --
>>> Interface MTU
>>>The size in octets of the largest address family specific datagram
>>>that can be sent on the associated interface without
>>>fragmentation.  The MTUs of common Internet link types can be
>>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>>>to 0 in Database Description packets sent over (OSPF3) virtual links.
>>>This recommendation MUST NOT be applied to tunnel and other virtual
>>>or software interfaces which carry traffic other than OSPF protocol 
>>> packets.
>>> 
>>> Notes
>>> -
>>> Currently, the language is ambiguous and at least one vendor has 
>>> implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly 
>>> others such as IPIP, IPSEC, etc., as I have not tested these). I believe 
>>> that the intent of the RFC is to refer strictly to OSPF virtual-links which 
>>> carry only OSPF protocol data and therefore have no meaningful MTU. When 
>>> this is mistakenly applied to other forms of "virtual" interfaces such as 
>>> tunnels, the results can be quite harmful.
>>> 
>>> As such, I think that clarification is in order, since the vendor in 
>>> question is unrepentant and claims their current implementation to be 
>>> compliant with the RFC.
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>> 
>>> --
>>> RFC5838 (draft-ietf-ospf-af-alt-10)
>>> --
>>> Title   : Support of Address Families in OSPFv3
>>> Publication Date: April 2010
>>> Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
>>> Aggarwal
>>> Category: PROPOSED STANDARD
>>> Source  : Open Shortest Path First IGP
>>> Area: Routing
>>> Stream  : IETF
>>> Verifying Party : IESG
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[John Scudder]

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.

—John

> On Sep 20, 2023, at 2:05 PM, Acee Lindem  wrote:
> 
> 
> I’m beginning to get a feeling of Deja MTU…
> 
> Acee
> 
>> On Sep 19, 2023, at 19:15, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC5340,
>> "OSPF for IPv6".
>> 
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7649__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-WbpxnM0kOok$
>> 
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>> 
>> Section: A.3.3 (in part)
>> 
>> Original Text
>> -
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over virtual links.
>> 
>> 
>> Corrected Text
>> --
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over OSPF virtual links. This rule should not be applied to tunnel
>> or other software interfaces.
>> 
>> Notes
>> -
>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
>> and this provision makes sense. For interfaces that have an actual MTU, even 
>> though they may be "virtual" interfaces, they are not "virtual links" in the 
>> intended meaning of this paragraph. As such, this change will provide 
>> clarification and remove ambiguity from the current standard. At least one 
>> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
>> interfaces which results in incompatibilities with most other router 
>> platforms which expect an actual value. The router vendor points to this 
>> provision in the RFCs as justification for their implementation. It is 
>> (arguably) a legitimate, if nonsensical interpretation of the existing text.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
>> --
>> Title   : OSPF for IPv6
>> Publication Date: July 2008
>> Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-Wbpxjmyny-M$
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[John Scudder]

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 consider this erratum, and 
determine whether it is correct and merits including in the update.” [1]

Please let me know soon if you have any concerns about that disposition.

--John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/


> On Sep 17, 2023, at 6:25 PM, Acee Lindem  wrote:
> 
> Given that the context of the “Interface MTU” is specifically the “interface 
> MTU” field in OSPFv3 Database Description packets and OSPF virtual links (RFC 
> 2328), the additions recommended in this Errata are unnecessary. The Errata 
> should be rejected.
> 
> Thanks,
> Acee
>> On Sep 17, 2023, at 15:58, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC5838,
>> "Support of Address Families in OSPFv3".
>> 
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
>> 
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>> 
>> Section: 2.7
>> 
>> Original Text
>> -
>>  Interface MTU
>> The size in octets of the largest address family specific datagram
>> that can be sent on the associated interface without
>> fragmentation.  The MTUs of common Internet link types can be
>> found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> to 0 in Database Description packets sent over virtual links.
>> 
>> 
>> Corrected Text
>> --
>>  Interface MTU
>> The size in octets of the largest address family specific datagram
>> that can be sent on the associated interface without
>> fragmentation.  The MTUs of common Internet link types can be
>> found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> to 0 in Database Description packets sent over (OSPF3) virtual links.
>> This recommendation MUST NOT be applied to tunnel and other virtual
>> or software interfaces which carry traffic other than OSPF protocol 
>> packets.
>> 
>> Notes
>> -
>> Currently, the language is ambiguous and at least one vendor has implemented 
>> OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as 
>> IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of 
>> the RFC is to refer strictly to OSPF virtual-links which carry only OSPF 
>> protocol data and therefore have no meaningful MTU. When this is mistakenly 
>> applied to other forms of "virtual" interfaces such as tunnels, the results 
>> can be quite harmful.
>> 
>> As such, I think that clarification is in order, since the vendor in 
>> question is unrepentant and claims their current implementation to be 
>> compliant with the RFC.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC5838 (draft-ietf-ospf-af-alt-10)
>> --
>> Title   : Support of Address Families in OSPFv3
>> Publication Date: April 2010
>> Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
>> Aggarwal
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Errata Verified] RFC2328 (7756)

[RFC Errata System]

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 Venkata Kumar Chakka 
Date Reported: 2024-01-11
Verified by: John Scudder (IESG)

Section: A.4.5

Original Text
-
AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
AS boundary routers, and describe destinations external to the AS.
For details concerning the construction of AS-external-LSAs, see
Section 12.4.3.

Corrected Text
--
AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
AS boundary routers, and describe destinations external to the AS.
For details concerning the construction of AS-external-LSAs, see
Section 12.4.4.

Notes
-
Incorrect references. Construction of AS-external-LSAs explained in Section 
12.4.4. Not in 12.4.

(See also 
https://mailarchive.ietf.org/arch/msg/lsr/OiOvEPM2W-Mwd_QgbmJASg8bDOI/)

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] [Errata Rejected] RFC2328 (7757)

[RFC Errata System]

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 Venkata Kumar Chakka 
Date Reported: 2024-01-11
Rejected by: John Scudder (IESG)

Section: A.4.5

Original Text
-
Forwarding address
Data traffic for the advertised destination will be forwarded to this address. 
If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded 
instead to the LSA's originator (i.e., the responsible AS boundary router).

Corrected Text
--
Forwarding address
Data traffic for the advertised destination will be forwarded to this address. 
If the Forwarding address is set to a Router ID address value other than 
0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's 
originator (i.e., the responsible AS boundary router).

Notes
-
Data traffic destined to the network indicated by Link State ID will be routed 
to that Router ID mentioned in forwarding address. If forwarding address is set 
to 0.0.0.0, it will be forwarded to LSA Originator itself.
 --VERIFIER NOTES-- 
   See https://mailarchive.ietf.org/arch/msg/lsr/_Xa4tym_roMmxFioFbrF3WRkKcM/

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Lokesh Chakka]

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 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.
> 
> 
> <1677214703247000_1695686347.png>
>  
> 
> 
> 
>  On Fri,12 Jan 2024 05:48:48 +0530 acee.i...@gmail.com wrote 
> 
> 
> 
> > 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 
> 
> 
> 
> > 
> > 
> > <1677214703247000_1695686347.png> 
> > 
> > 
> > 
> > 
> >  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 debate me on this point. If you make this 
> > assumption, you should open an Errata on your implementation. 
> > 
> > Excerpted from RFC 2328: 
> > 
> > Router ID 
> > A 32-bit number assigned to each router running the OSPF 
> > protocol. This number uniquely identifies the router within 
> > an Autonomous System. 
> > 
> > OSPF Router IDs need NOT be routable. 
> > 
> > Acee 
> > 
> > 
> > 
> > > 
> > > 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. 
> > > 
> > > 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". 
> > > > 
> > > > -- 
> > > > You may review the report below and at: 
> > > > https://www.rfc-editor.org/errata/eid7757 
> > > > 
> > > > -- 
> > > > Type: Technical 
> > > > Reported by: Lokesh Venkata Kumar Chakka  
> > > > 
> > > > Section: A.4.5 
> > > > 
> > > > Original Text 
> > > > - 
> > > > Forwarding address 
> > > > Data traffic for the advertised destination will be forwarded to this 
> > > > address. If the Forwarding address is set to 0.0.0.0, data traffic will 
> > > > be forwarded instead to the LSA's originator (i.e., the responsible AS 
> > > > boundary router). 
> > > > 
> > > > Corrected Text 
> > > > -- 
> > > > Forwarding address 
> > > > Data traffic for the advertised destination will be forwarded to this 
> > > > address. If the Forwarding address is set to a Router ID address value 
> > > > other than 0.0.0.0, data traffic will be forwarded to that Router 
> > > > instead to the LSA's originator (i.e., the responsible AS boundary 
> > > > router). 
> > > > 
> > > > Notes 
> > > > - 
> > > > Data traffic destined to the network indicated by Link State ID will be 
> > > > routed to that Router ID mentioned in forwarding address. If forwarding 
> > > > address is set to 0.0.0.0, it will be forwarded to LSA Originator 
> > > > itself. 
> > > > 
> > > > Instructions: 
> > > > - 
> > > > This erratum is currently posted as "Reported". (If it is spam, it 
> > > > will be removed shortly by the RFC Production Center.) Please 
> > > > use "Reply All" to discuss whether it should be verified or 
> > > > rejected. When a decision is reached, the verifying party 
> > > > will log in to change the status and edit the report, if necessary. 
> > > > 
> > > > -- 
> > > > RFC2328 (no draft string recorded) 
> > > > -- 
> > > > Title : OSPF Version 2 
> > > > Publication Date : April 1998 
> > > > Author(s) : J. Moy 
> > > > Category : INTERNET STANDARD 
> > > > Source : Open Shortest Path First IGP 
> > > > Area : Routing 
> > > > Stream : IETF 
> > > > Verifying Party : IESG 
> > > > 
> > > > ___ 
> > > > Lsr mailing list 
> > > > Lsr@ietf.org 
> > > > https://www.ietf.org/mailman/listinfo/lsr 
> > > 
> > > 
> > 
> > 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Acee Lindem]

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.
> 
> 
> <1677214703247000_1695686347.png>
>  
> 
> 
> 
>  On Fri,12 Jan 2024 05:48:48 +0530 acee.i...@gmail.com wrote 
> 
> 
> 
> > 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 
> 
> 
> 
> > 
> > 
> > <1677214703247000_1695686347.png> 
> > 
> > 
> > 
> > 
> >  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 debate me on this point. If you make this 
> > assumption, you should open an Errata on your implementation. 
> > 
> > Excerpted from RFC 2328: 
> > 
> > Router ID 
> > A 32-bit number assigned to each router running the OSPF 
> > protocol. This number uniquely identifies the router within 
> > an Autonomous System. 
> > 
> > OSPF Router IDs need NOT be routable. 
> > 
> > Acee 
> > 
> > 
> > 
> > > 
> > > 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. 
> > > 
> > > 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". 
> > > > 
> > > > -- 
> > > > You may review the report below and at: 
> > > > https://www.rfc-editor.org/errata/eid7757 
> > > > 
> > > > -- 
> > > > Type: Technical 
> > > > Reported by: Lokesh Venkata Kumar Chakka  
> > > > 
> > > > Section: A.4.5 
> > > > 
> > > > Original Text 
> > > > - 
> > > > Forwarding address 
> > > > Data traffic for the advertised destination will be forwarded to this 
> > > > address. If the Forwarding address is set to 0.0.0.0, data traffic will 
> > > > be forwarded instead to the LSA's originator (i.e., the responsible AS 
> > > > boundary router). 
> > > > 
> > > > Corrected Text 
> > > > -- 
> > > > Forwarding address 
> > > > Data traffic for the advertised destination will be forwarded to this 
> > > > address. If the Forwarding address is set to a Router ID address value 
> > > > other than 0.0.0.0, data traffic will be forwarded to that Router 
> > > > instead to the LSA's originator (i.e., the responsible AS boundary 
> > > > router). 
> > > > 
> > > > Notes 
> > > > - 
> > > > Data traffic destined to the network indicated by Link State ID will be 
> > > > routed to that Router ID mentioned in forwarding address. If forwarding 
> > > > address is set to 0.0.0.0, it will be forwarded to LSA Originator 
> > > > itself. 
> > > > 
> > > > Instructions: 
> > > > - 
> > > > This erratum is currently posted as "Reported". (If it is spam, it 
> > > > will be removed shortly by the RFC Production Center.) Please 
> > > > use "Reply All" to discuss whether it should be verified or 
> > > > rejected. When a decision is reached, the verifying party 
> > > > will log in to change the status and edit the report, if necessary. 
> > > > 
> > > > -- 
> > > > RFC2328 (no draft string recorded) 
> > > > -- 
> > > > Title : OSPF Version 2 
> > > > Publication Date : April 1998 
> > > > Author(s) : J. Moy 
> > > > Category : INTERNET STANDARD 
> > > > Source : Open Shortest Path First IGP 
> > > > Area : Routing 
> > > > Stream : IETF 
> > > > Verifying Party : IESG 
> > > > 
> > > > ___ 
> > > > Lsr mailing list 
> > > > Lsr@ietf.org 
> > > > https://www.ietf.org/mailman/listinfo/lsr 
> > > 
> > > 
> > 
> > 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Lokesh Chakka]

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 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



> 
> 
> <1677214703247000_1695686347.png>
>  
> 
> 
> 
>  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 debate me on this point. If you make this 
> assumption, you should open an Errata on your implementation. 
> 
> Excerpted from RFC 2328: 
> 
> Router ID 
> A 32-bit number assigned to each router running the OSPF 
> protocol. This number uniquely identifies the router within 
> an Autonomous System. 
> 
> OSPF Router IDs need NOT be routable. 
> 
> Acee 
> 
> 
> 
> > 
> > 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. 
> > 
> > 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". 
> > > 
> > > -- 
> > > You may review the report below and at: 
> > > https://www.rfc-editor.org/errata/eid7757 
> > > 
> > > -- 
> > > Type: Technical 
> > > Reported by: Lokesh Venkata Kumar Chakka  
> > > 
> > > Section: A.4.5 
> > > 
> > > Original Text 
> > > - 
> > > Forwarding address 
> > > Data traffic for the advertised destination will be forwarded to this 
> > > address. If the Forwarding address is set to 0.0.0.0, data traffic will 
> > > be forwarded instead to the LSA's originator (i.e., the responsible AS 
> > > boundary router). 
> > > 
> > > Corrected Text 
> > > -- 
> > > Forwarding address 
> > > Data traffic for the advertised destination will be forwarded to this 
> > > address. If the Forwarding address is set to a Router ID address value 
> > > other than 0.0.0.0, data traffic will be forwarded to that Router instead 
> > > to the LSA's originator (i.e., the responsible AS boundary router). 
> > > 
> > > Notes 
> > > - 
> > > Data traffic destined to the network indicated by Link State ID will be 
> > > routed to that Router ID mentioned in forwarding address. If forwarding 
> > > address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. 
> > > 
> > > Instructions: 
> > > - 
> > > This erratum is currently posted as "Reported". (If it is spam, it 
> > > will be removed shortly by the RFC Production Center.) Please 
> > > use "Reply All" to discuss whether it should be verified or 
> > > rejected. When a decision is reached, the verifying party 
> > > will log in to change the status and edit the report, if necessary. 
> > > 
> > > -- 
> > > RFC2328 (no draft string recorded) 
> > > -- 
> > > Title : OSPF Version 2 
> > > Publication Date : April 1998 
> > > Author(s) : J. Moy 
> > > Category : INTERNET STANDARD 
> > > Source : Open Shortest Path First IGP 
> > > Area : Routing 
> > > Stream : IETF 
> > > Verifying Party : IESG 
> > > 
> > > ___ 
> > > Lsr mailing list 
> > > Lsr@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/lsr 
> > 
> > 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Acee Lindem]

> 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



> 
> 
> <1677214703247000_1695686347.png>
>  
> 
> 
> 
>  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 debate me on this point. If you make this 
> assumption, you should open an Errata on your implementation. 
> 
> Excerpted from RFC 2328: 
> 
> Router ID 
> A 32-bit number assigned to each router running the OSPF 
> protocol. This number uniquely identifies the router within 
> an Autonomous System. 
> 
> OSPF Router IDs need NOT be routable. 
> 
> Acee 
> 
> 
> 
> > 
> > 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. 
> > 
> > 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". 
> > > 
> > > -- 
> > > You may review the report below and at: 
> > > https://www.rfc-editor.org/errata/eid7757 
> > > 
> > > -- 
> > > Type: Technical 
> > > Reported by: Lokesh Venkata Kumar Chakka  
> > > 
> > > Section: A.4.5 
> > > 
> > > Original Text 
> > > - 
> > > Forwarding address 
> > > Data traffic for the advertised destination will be forwarded to this 
> > > address. If the Forwarding address is set to 0.0.0.0, data traffic will 
> > > be forwarded instead to the LSA's originator (i.e., the responsible AS 
> > > boundary router). 
> > > 
> > > Corrected Text 
> > > -- 
> > > Forwarding address 
> > > Data traffic for the advertised destination will be forwarded to this 
> > > address. If the Forwarding address is set to a Router ID address value 
> > > other than 0.0.0.0, data traffic will be forwarded to that Router instead 
> > > to the LSA's originator (i.e., the responsible AS boundary router). 
> > > 
> > > Notes 
> > > - 
> > > Data traffic destined to the network indicated by Link State ID will be 
> > > routed to that Router ID mentioned in forwarding address. If forwarding 
> > > address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. 
> > > 
> > > Instructions: 
> > > - 
> > > This erratum is currently posted as "Reported". (If it is spam, it 
> > > will be removed shortly by the RFC Production Center.) Please 
> > > use "Reply All" to discuss whether it should be verified or 
> > > rejected. When a decision is reached, the verifying party 
> > > will log in to change the status and edit the report, if necessary. 
> > > 
> > > -- 
> > > RFC2328 (no draft string recorded) 
> > > -- 
> > > Title : OSPF Version 2 
> > > Publication Date : April 1998 
> > > Author(s) : J. Moy 
> > > Category : INTERNET STANDARD 
> > > Source : Open Shortest Path First IGP 
> > > Area : Routing 
> > > Stream : IETF 
> > > Verifying Party : IESG 
> > > 
> > > ___ 
> > > Lsr mailing list 
> > > Lsr@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/lsr 
> > 
> > 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Lokesh Chakka]

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 debate me on this point. If you make this assumption, 
you should open an Errata on your implementation. 

Excerpted  from RFC 2328:

 Router ID
 A 32-bit number assigned to each router running the OSPF
 protocol. This number uniquely identifies the router within
  an Autonomous System.

OSPF Router IDs need NOT be routable. 

Acee



> 
> 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. 
> 
> 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". 
> > 
> > -- 
> > You may review the report below and at: 
> > https://www.rfc-editor.org/errata/eid7757 
> > 
> > -- 
> > Type: Technical 
> > Reported by: Lokesh Venkata Kumar Chakka  
> > 
> > Section: A.4.5 
> > 
> > Original Text 
> > - 
> > Forwarding address 
> > Data traffic for the advertised destination will be forwarded to this 
> > address. If the Forwarding address is set to 0.0.0.0, data traffic will be 
> > forwarded instead to the LSA's originator (i.e., the responsible AS 
> > boundary router). 
> > 
> > Corrected Text 
> > -- 
> > Forwarding address 
> > Data traffic for the advertised destination will be forwarded to this 
> > address. If the Forwarding address is set to a Router ID address value 
> > other than 0.0.0.0, data traffic will be forwarded to that Router instead 
> > to the LSA's originator (i.e., the responsible AS boundary router). 
> > 
> > Notes 
> > - 
> > Data traffic destined to the network indicated by Link State ID will be 
> > routed to that Router ID mentioned in forwarding address. If forwarding 
> > address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. 
> > 
> > Instructions: 
> > - 
> > This erratum is currently posted as "Reported". (If it is spam, it 
> > will be removed shortly by the RFC Production Center.) Please 
> > use "Reply All" to discuss whether it should be verified or 
> > rejected. When a decision is reached, the verifying party 
> > will log in to change the status and edit the report, if necessary. 
> > 
> > -- 
> > RFC2328 (no draft string recorded) 
> > -- 
> > Title : OSPF Version 2 
> > Publication Date : April 1998 
> > Author(s) : J. Moy 
> > Category : INTERNET STANDARD 
> > Source : Open Shortest Path First IGP 
> > Area : Routing 
> > Stream : IETF 
> > Verifying Party : IESG 
> > 
> > ___ 
> > Lsr mailing list 
> > Lsr@ietf.org 
> > https://www.ietf.org/mailman/listinfo/lsr 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Editorial Errata Reported] RFC2328 (7756)

[Acee Lindem]

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:
> https://www.rfc-editor.org/errata/eid7756
> 
> --
> Type: Editorial
> Reported by: Lokesh Venkata Kumar Chakka 
> 
> Section: A.4.5
> 
> Original Text
> -
> AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS 
> boundary routers, and describe destinations external to the AS. For details 
> concerning the construction of AS-external-LSAs, see Section 12.4.3
> 
> Corrected Text
> --
> AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS 
> boundary routers, and describe destinations external to the AS. For details 
> concerning the construction of AS-external-LSAs, see Section 12.4.4
> 
> Notes
> -
> Incorrect references. Construction of AS-external-LSAs explained in Section 
> 12.4.4. Not in 12.4.3
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC2328 (no draft string recorded)
> --
> Title   : OSPF Version 2
> Publication Date: April 1998
> Author(s)   : J. Moy
> Category: INTERNET STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Acee Lindem]

> 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 2328:

 Router ID
 A 32-bit number assigned to each router running the OSPF
 protocol. This number uniquely identifies the router within
  an Autonomous System.

OSPF Router IDs need NOT be routable. 

Acee



> 
> 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. 
> 
> 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". 
> > 
> > -- 
> > You may review the report below and at: 
> > https://www.rfc-editor.org/errata/eid7757 
> > 
> > -- 
> > Type: Technical 
> > Reported by: Lokesh Venkata Kumar Chakka  
> > 
> > Section: A.4.5 
> > 
> > Original Text 
> > - 
> > Forwarding address 
> > Data traffic for the advertised destination will be forwarded to this 
> > address. If the Forwarding address is set to 0.0.0.0, data traffic will be 
> > forwarded instead to the LSA's originator (i.e., the responsible AS 
> > boundary router). 
> > 
> > Corrected Text 
> > -- 
> > Forwarding address 
> > Data traffic for the advertised destination will be forwarded to this 
> > address. If the Forwarding address is set to a Router ID address value 
> > other than 0.0.0.0, data traffic will be forwarded to that Router instead 
> > to the LSA's originator (i.e., the responsible AS boundary router). 
> > 
> > Notes 
> > - 
> > Data traffic destined to the network indicated by Link State ID will be 
> > routed to that Router ID mentioned in forwarding address. If forwarding 
> > address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. 
> > 
> > Instructions: 
> > - 
> > This erratum is currently posted as "Reported". (If it is spam, it 
> > will be removed shortly by the RFC Production Center.) Please 
> > use "Reply All" to discuss whether it should be verified or 
> > rejected. When a decision is reached, the verifying party 
> > will log in to change the status and edit the report, if necessary. 
> > 
> > -- 
> > RFC2328 (no draft string recorded) 
> > -- 
> > Title : OSPF Version 2 
> > Publication Date : April 1998 
> > Author(s) : J. Moy 
> > Category : INTERNET STANDARD 
> > Source : Open Shortest Path First IGP 
> > Area : Routing 
> > Stream : IETF 
> > Verifying Party : IESG 
> > 
> > ___ 
> > Lsr mailing list 
> > Lsr@ietf.org 
> > https://www.ietf.org/mailman/listinfo/lsr 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Lokesh]

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. 

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".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7757
> 
> --
> Type: Technical
> Reported by: Lokesh Venkata Kumar Chakka 
> 
> Section: A.4.5
> 
> Original Text
> -
> Forwarding address
> Data traffic for the advertised destination will be forwarded to this 
> address. If the Forwarding address is set to 0.0.0.0, data traffic will be 
> forwarded instead to the LSA's originator (i.e., the responsible AS boundary 
> router).
> 
> Corrected Text
> --
> Forwarding address
> Data traffic for the advertised destination will be forwarded to this 
> address. If the Forwarding address is set to a Router ID address value other 
> than 0.0.0.0, data traffic will be forwarded to that Router instead to the 
> LSA's originator (i.e., the responsible AS boundary router).
> 
> Notes
> -
> Data traffic destined to the network indicated by Link State ID will be 
> routed to that Router ID mentioned in forwarding address. If forwarding 
> address is set to 0.0.0.0, it will be forwarded to LSA Originator itself.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC2328 (no draft string recorded)
> --
> Title   : OSPF Version 2
> Publication Date: April 1998
> Author(s)   : J. Moy
> Category: INTERNET STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Technical Errata Reported] RFC2328 (7757)

[Acee Lindem]

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".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7757
> 
> --
> Type: Technical
> Reported by: Lokesh Venkata Kumar Chakka 
> 
> Section: A.4.5
> 
> Original Text
> -
> Forwarding address
> Data traffic for the advertised destination will be forwarded to this 
> address. If the Forwarding address is set to 0.0.0.0, data traffic will be 
> forwarded instead to the LSA's originator (i.e., the responsible AS boundary 
> router).
> 
> Corrected Text
> --
> Forwarding address
> Data traffic for the advertised destination will be forwarded to this 
> address. If the Forwarding address is set to a Router ID address value other 
> than 0.0.0.0, data traffic will be forwarded to that Router instead to the 
> LSA's originator (i.e., the responsible AS boundary router).
> 
> Notes
> -
> Data traffic destined to the network indicated by Link State ID will be 
> routed to that Router ID mentioned in forwarding address. If forwarding 
> address is set to 0.0.0.0, it will be forwarded to LSA Originator itself.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC2328 (no draft string recorded)
> --
> Title   : OSPF Version 2
> Publication Date: April 1998
> Author(s)   : J. Moy
> Category: INTERNET STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[The IESG]

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 comments to the
last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



No IPR declarations have been submitted directly on this I-D.





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Lizhenbin]

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 "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024. 

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Gengxuesong (Geng Xuesong)]

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 mechanism to build SR based NRPs in those scenarios.  The
   resource-aware segments can be used with this approach to provide
   resource guaranteed SR based NRPs, while the normal SR segments may
   also be used to provide SR based NRPs with shared network resources
   in the forwarding plane.

   The proposed approach is to use IS-IS Multi-Topology [RFC5120] with
   segment routing [RFC8667] to define the independent network topology
   of each NRP.  The network resources and other TE attributes of an NRP
   can be advertised using IS-IS MT with the Traffic Engineering (TE)
   extensions defined in [RFC5305] and [RFC8570].

[Xuesong] I recommend to swap the position of these two sentences. It will be 
easier for readers' understanding: show what is the proposal firstly and then 
describe this could be used with resource-aware segments to provide resource 
guaranteed SR based NRPs

2.  Advertisement of Topology Attribute for SR based NRP

[Xuesong] It will be helpful if there is a summary about what Topology 
Attribute for SR based NRP is requested before introducing what could be reused 
in different existing RFCs.

3.  Advertisement of Resource Attribute for SR based NRP

   In order to perform constraint based path computation for each NRP on
   the network controller or on the ingress nodes, the network resource
   attributes and other attributes associated with each NRP need to be
   advertised.

[Xuesong] It could be considered to add some explanation for whether this is 
just for this proposal or also could be used to other resource guaranteed SR 
based NRPs


5.  Scalability Considerations
  The
   mechanism described in this document is considered useful for network
   scenarios in which the required number of NRP is small, as no control
   protocol extension is required.  For network scenarios where the
   number of required NRP is large, more scalable solution would be
   needed, which may require further protocol extensions and
   enhancements.

[Xuesong] This is helpful to add some reference for example of more scalable 
solutions.


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Tuesday, January 9, 2024 6:50 AM
> To: Lsr 
> Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS 
> Multi-Topology
> (MT) for Segment Routing based Network Resource Partition (NRP)" -
> draft-ietf-lsr-isis-sr-vtn-mt-06
> 
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS
> Multi-Topology (MT) for Segment Routing based Network Resource Partition
> (NRP)”. Please express your support or objection prior to Tuesday, January 
> 23rd,
> 2024.
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Huzhibo]

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.

Thanks
Zhibo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, January 9, 2024 6:50 AM
To: Lsr 
Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024. 

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Gyan Mishra]

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).

https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-25

Jie & myself are Co-authors of this draft and maybe we can both try to
explain what this is saying and why it does not preclude use of ISIS MT or
even Flex Algo for IETF network slicing.

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl


“The routing protocols (IGP or BGP) do not need to be involved in any of
these points, and it is important to isolate them from these aspects in
order that there is no impact on scaling or stability. Furthermore, the
complexity of SPF in the control plan is unaffected by this.”

So this section 3 is talking about NRP scalability design principles which
are listed and is talking about NRP scalability which is data plane
scalability for the underlying underlay resource NRP.

So the NRP is independent of the routing control plane which MT is common
control plane and separate data plane which allows for more scalability of
network slicing as compared to MI Multi Instance which has separation of
control plane and data plane.  So what the text is talking about is the
data plane aspects of the control plane function is what is related to NRP
and not the routing control plane itself.

Kind Regards



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Wed, Jan 10, 2024 at 7:21 PM Les Ginsberg (ginsberg)  wrote:

> (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 draft-ietf-lsr-isis-sr-vtn-mt.
>
>
>
> It is certainly true, as Joel points out, that this draft references many
> drafts which are not yet RFCs – and in some cases are not even WG
> documents. Therefore, it is definitely premature to last call this draft.
>
>
>
> I also want to point out that the direction TEAS WG has moved to
> recommends that routing protocols NOT be used as a means of supporting NRP.
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
> states:
>
>
>
> *“…it is desirable for NRPs to have no more than small impact (zero being
> preferred) on the IGP information that is propagated today, and to not
> required additional SPF computations beyond those that are already
> required.”*
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
> states:
>
>
>
> *“The routing protocols (IGP or BGP) do not need to be involved in any of
> these points, and it is important to isolate them from these aspects in
> order that there is no impact on scaling or stability.”*
>
>
>
> Another draft which is referenced is
> https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which
> is not a WG document and – based on the recommendations in
> draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be
> extended as proposed in this draft. So if a WG adoption call were to
> initiated for draft-dong-lsr-sr-enhanced-vpn, I would oppose it.
>
>
>
> This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing
> information about a solution which the IETF is discouraging. I do not know
> why the IETF would want to do this.
>
>
>
> If, despite all of the above, at some point it is judged not premature to
> publish this draft, I think the draft should at least include statements
> indicating that this approach is not a recommended deployment solution.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Joel Halpern
> *Sent:* Wednesday, January 10, 2024 3:22 PM
> *To:* Acee Lindem ; t...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] [Teas] Fwd: Working Group Last Call for
> "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based
> Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
>
>
>
> 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 an Informative
> reference.
>
> Yours,
>
> Joel
>
> PS: I considered not writing this email, as it seems quite reasonable to
> use MT to support what I expect NRPs to be.  So in principle I think the
> document is a good idea.
>
> On 1/10/2024 6:12 PM, Acee Lindem wrote:
>
> Note that we are last calling this informational document relating 

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Gyan Mishra]

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. It defines the term "IETF Network Slice" to
describe this type of network slice, and establishes the general principles
of network slicing in the IETF context.¶



Applicability of network slicing to SR-MPLS or SRv6 forwarding plane using
IETF technologies, encoding NRP-ID using  ISIS MT per MTID instance NRP
Network slice to be  instantiated.

Thanks



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Mon, Jan 8, 2024 at 5:50 PM Acee Lindem  wrote:

> This begins a two week LSR Working Group last call for the “Applicability
> of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource
> Partition (NRP)”. Please express your support or objection prior to
> Tuesday, January 23rd, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Wei Wang]

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 further.




Best Regards,
Wei



--Original--
From:   
 "Acee Lindem"  
  
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr