[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

2024-01-31 Thread Murray Kucherawy via Datatracker 
Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-ospfv3-extended-lsa-yang-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



--
COMMENT:
--

Forwarding a comment from Orie Steele, incoming ART AD:

There do not appear to be a lot of normative statements.



___
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

2024-01-31 Thread Gengxuesong (Geng Xuesong) 
Hi Chongfeng,

Thanks for updating the document and the new version looks good to me.

Best
Xuesong

From: Chongfeng Xie [mailto:chongfeng@foxmail.com]
Sent: Tuesday, January 23, 2024 11:33 AM
To: Gengxuesong (Geng Xuesong) ; Acee Lindem 
; lsr 
Subject: Re: 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


Hi Xuesong,

Thanks for your support and review comments. We are working on a new revision 
which will take your comments into consideration.

As for your suggestion to add reference to the more scalable solution, 
according to the comments from Acee, we would not mention the specific solution 
in this draft, but we have referred to the NRP scalability document for more 
information on the scalability discussion.  Hope that would be OK to you.

Best regards,
Chongfeng

From: Gengxuesong (Geng Xuesong)
Date: 2024-01-11 18:37
To: Acee Lindem; Lsr
Subject: 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
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 mailto:lsr@ietf.org>>
> 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] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

2024-01-31 Thread Acee Lindem 


> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
> 
> 
> 
>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker  
>> wrote:
>> 
>> Roman Danyliw has entered the following ballot position for
>> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to 
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> ** Section 5.
>> 
>>  Write
>>  operations (e.g., edit-config) to these data nodes without proper
>>  protection can have a negative effect on network operations.  There
>>  are the subtrees and data nodes and their sensitivity/vulnerability:
>> 
>> /ospf:ospf/extended-lsa-support
>> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>> The ability to disable OSPFv3 Extended LSA support can result in a
>> denial of service.
>> 
>> Isn’t it more than just denial of service?  In certain environments wouldn’t
>> the ability to modify OSPF Extended LSA configurations enable an attacker to:
>> modify network topologies to enable select traffic to avoid inspection or
>> treatment by security controls; route traffic in a way that it would be 
>> subject
>> to inspect/modification by an adversary node; or gain access to otherwise
>> segregated parts of the network.
> 
> Only if they were able to craft extended LSAs on behalf of the original as 
> well as
> modify the YANG configuration added by this document. I didn’t think we’d 
> have to
> reiterate all the possible protocol attacks for every incremental enhancement.

Furthermore, no one is going to use the support of extended LSAs to isolate 
OSPFv3 domains 
from one another. The configuration is to control migration to the extended LSA 
encodings.
Please see RFC 8362 for more information on OSPFv3 Extended LSAs.  

Acee





> 
> Acee
> 
> 
> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> As an editorial note, I would have benefit from some narrative prose on the 
>> data model.

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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

2024-01-31 Thread Acee Lindem 


> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker  
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> ** Section 5.
> 
>   Write
>   operations (e.g., edit-config) to these data nodes without proper
>   protection can have a negative effect on network operations.  There
>   are the subtrees and data nodes and their sensitivity/vulnerability:
> 
>  /ospf:ospf/extended-lsa-support
>  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>  The ability to disable OSPFv3 Extended LSA support can result in a
>  denial of service.
> 
> Isn’t it more than just denial of service?  In certain environments wouldn’t
> the ability to modify OSPF Extended LSA configurations enable an attacker to:
> modify network topologies to enable select traffic to avoid inspection or
> treatment by security controls; route traffic in a way that it would be 
> subject
> to inspect/modification by an adversary node; or gain access to otherwise
> segregated parts of the network.

Only if they were able to craft extended LSAs on behalf of the original as well 
as
modify the YANG configuration added by this document. I didn’t think we’d have 
to
reiterate all the possible protocol attacks for every incremental enhancement.

Acee



> 
> 
> --
> COMMENT:
> --
> 
> As an editorial note, I would have benefit from some narrative prose on the 
> data model.
> 
> 
> 

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

[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

2024-01-31 Thread Roman Danyliw via Datatracker 
Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



--
DISCUSS:
--

** Section 5.

   Write
   operations (e.g., edit-config) to these data nodes without proper
   protection can have a negative effect on network operations.  There
   are the subtrees and data nodes and their sensitivity/vulnerability:

  /ospf:ospf/extended-lsa-support
  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
  The ability to disable OSPFv3 Extended LSA support can result in a
  denial of service.

Isn’t it more than just denial of service?  In certain environments wouldn’t
the ability to modify OSPF Extended LSA configurations enable an attacker to:
modify network topologies to enable select traffic to avoid inspection or
treatment by security controls; route traffic in a way that it would be subject
to inspect/modification by an adversary node; or gain access to otherwise
segregated parts of the network.


--
COMMENT:
--

As an editorial note, I would have benefit from some narrative prose on the 
data model.



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