Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Alan DeKok]

On Feb 8, 2023, at 2:38 PM, Rob Wilton (rwilton)  wrote:
> To give a regular configuration example, if you were to enable the Ethernet 
> auto-negotiation protocol but also explicitly configure an 10/100/1000 
> Ethernet interface to run at 100 Mb/s then I would expect the explicit client 
> provided configuration to take precedence over negotiating the speed value.
> 
> It sounds like, in what you describe, the configuration is effectively 
> hierarchical.  I.e., it is really because the RADIUS supplied configuration 
> is more-specific that it takes precedence over the local configuration.  If 
> so, that is expected, but I think that it would be helpful to clarify the 
> description to make that clear.

  OK, thanks.

>>  It's a limitation of RADIUS.  Everything RADIUS has to support 4K packets.
>> Later RFCs allow for 64K packets.
> [Rob Wilton (rwilton)] 
> 
> Okay.  If this will be obvious to everyone implementing/deploying RADIUS then 
> fine, otherwise it might be worth including an informative reference to the 
> RFC that increases the limit to 64K.

  This is RFC 7930.  Packet size limitations will be obvious to everyone 
implementing RADIUS.

  Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Alan,

Sorry for the delay.  Please see inline ...

> -Original Message-
> From: Alan DeKok 
> Sent: 19 December 2022 17:13
> To: Rob Wilton (rwilton) 
> Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org; opsawg@ietf.org
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
> 
> On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton)
>  wrote:
> > It isn't really clear to me why some of the registries are needed, 
> > specifically
> the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6 DHCP attribute to be
> carried within the DHCPv6-Options or DHCPv4-Options field?
> 
>   The original intent of the document was to define a limited set of DHCP
> options which could be carried in RADIUS.  i.e. option X would map to RADIUS
> attribute Y.  After some discussion, this was deemed to be unworkable, and
> changed to the current method.
> 
>   The previous limitations were still kept, however.
> 
>   While it is useful, I could see issues with allowing any DHCP option to be
> transported in RADIUS.  I'll have to dig deeper to get into details.
[Rob Wilton (rwilton)] 

Okay.

> 
> >
> > (2) p 4, sec 3.  DHCP Options RADIUS Attributes
> >
> >   Absent any explicit configuration on the DHCP server, RADIUS supplied
> >   data by means of DHCP*-Options Attributes take precedence over any
> >   local configuration.
> >
> > This point may be worth discussing.  Naturally, I would explicit 
> > configuration
> to a network device to generally take precedent over implicitly learned
> configuration from the network.
> 
>  I'm not sure which options are "implicitly learned" from the network.  One 
> set
> is configured in the device, and another is configured on a per-user / per-
> session basis.  This allows for sane defaults, with specific over-rides where
> those are needed.
> 
>   If the options configured on the device always take precedence over the per-
> session options (via RADIUS), then there isn't much point in sending 
> per-session
> options.
[Rob Wilton (rwilton)] 
To give a regular configuration example, if you were to enable the Ethernet 
auto-negotiation protocol but also explicitly configure an 10/100/1000 Ethernet 
interface to run at 100 Mb/s then I would expect the explicit client provided 
configuration to take precedence over negotiating the speed value.

It sounds like, in what you describe, the configuration is effectively 
hierarchical.  I.e., it is really because the RADIUS supplied configuration is 
more-specific that it takes precedence over the local configuration.  If so, 
that is expected, but I think that it would be helpful to clarify the 
description to make that clear.


> 
> > (3) p 6, sec 3.2.  DHCPv4-Options Attribute
> >
> >  Permitted DHCPv4 options in the DHCPv4-Options Attribute are
> >  maintained by IANA in the registry created in Section 8.4.2.
> >
> > Comparing this text to the description for v6, this description is silent on
> whether multiple instances of the same DHCPv4 option MAY be included.
> Should that be specified here?
> 
>   Likely, yes.  The RADIUS attributes are simply carrying DHCP options, as if 
> they
> were in a DHCP packet.  So all of the DHCP rules about option handling should
> apply here.
[Rob Wilton (rwilton)] 
Okay.

> 
> >
> > (4) p 10, sec 7.  Table of Attributes
> >
> >   The following table provides a guide as what type of RADIUS packets
> >   that may contain these attributes, and in what quantity.
> >
> > Am I right that this is just a duplication of what is described in section 
> > 3?  If
> so, perhaps change "guide" to "informative guide" and include text to refer
> back to the  canonical definition in section 3.
> 
>   Sure.  This table is traditional in RADIUS RFCs, so the text here mirrors
> previous RADIUS RFCs.
[Rob Wilton (rwilton)] 
Okay.


> 
> > (8) p 3, sec 3.  DHCP Options RADIUS Attributes
> >
> >   These attributes use the "Long Extended Type" format in order to
> >   permit the transport of attributes encapsulating more than 253 octets
> >   of data.  DHCP options that can be included in the DHCP*-Options
> >   RADIUS attributes are limited by the maximum packet size of 4096
> >   bytes.  In order to accommodate deployments with large options,
> >   implementations are RECOMMENDED to support a packet size up to 65535
> >   bytes.
> >
> > I didn't find this text clear.  E.g., limit is 4k but should support up to 
> > 64K.
> Which implementations should support larger packet sizes?  Is this RADIUS
> implementations?
> 
>   It's a limitation of RADIUS.  Everything RADIUS has to support 4K packets.
> Later RFCs allow for 64K packets.
[Rob Wilton (rwilton)] 

Okay.  If this will be obvious to everyone implementing/deploying RADIUS then 
fine, otherwise it might be worth including an informative reference to the RFC 
that increases the limit to 64K.



> 
> >
> > (9) p 5, sec 3.1.  DHCPv6-Options Attribute
> >
> >  This field contains a list of DHCPv6 options.  Multiple instances
> >  of 

Re: [OPSAWG] draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. (slice) service provisioning

[Richard Roberts]

Hi all,

I am sharing with you the link below that deals with TN Slices within ORAN. 
This is joint WG6 (O-CLOUD) and WG9 (TN) presentation.
This presentation shows how the AC Data model can complement the Network Slice 
Service DM to create a new slice (example of a vlan hand-off model - different 
options are possible -).

https://github.com/boucadair/attachment-circuit-model/blob/main/assets/JNPR-WG6-WG9-E2E-TN-31012023.pdf

There are also a few slides related to provide better Transport Network 
automation within the  5G SMO, by extending the 3GPP Network Resource Model 
with the IETF AC YANG DM (EP_TRANSPORT/NextHopInfo). In other words, use IETF 
for network plumbing within the 3GPP ecosystem.

Of course, feel free to reach out to me if you have any questions !

Regards,
R


Juniper Business Use Only
From: mohamed.boucad...@orange.com 
Sent: Friday, January 20, 2023 2:17 PM
To: TEAS WG ; 
draft-ietf-teas-ietf-network-slice-nbi-y...@ietf.org
Cc: opsawg@ietf.org; Richard Roberts ; Bo Wu 
; Oscar Gonzalez de Dios 
; Samier Barguil 
; JACQUENET Christian INNOV/NET 

Subject: RE: draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. 
(slice) service provisioning

[External Email. Be cautious of content]

Hi all,

We updated the draft with many examples to illustrate the use of the model. A 
new subsection was added to illustrate how slices can be bound pre-provisioned 
AC. The service slice model can be greatly simplified by imply relying upon the 
AC model. At this stage, we are defining a new model that augments the slice 
service model, but a proposal to discuss is: remove all the AC details from the 
slice service model and simply move the ac-ref into the main slice model.

We also updated the model to cover bearers managements and refined some of 
existing containers.

More changes can be tracked using the following links:


URL:
https://www.ietf.org/archive/id/draft-boro-opsawg-teas-attachment-circuit-01.txt

Status: 
https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-attachment-circuit/

Html:   
https://www.ietf.org/archive/id/draft-boro-opsawg-teas-attachment-circuit-01.html

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-boro-opsawg-teas-attachment-circuit

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-boro-opsawg-teas-attachment-circuit-01

We are seeking for more use cases to exercise the model.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 10 janvier 2023 11:36
À : TEAS WG mailto:t...@ietf.org>>
Cc : opsawg@ietf.org; Richard Roberts 
mailto:rrobe...@juniper.net>>; Bo Wu 
mailto:lana.w...@huawei.com>>; Oscar Gonzalez de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 Samier Barguil 
mailto:samier.barguil_gira...@nokia.com>>; 
JACQUENET Christian INNOV/NET 
mailto:christian.jacque...@orange.com>>
Objet : draft-ietf-teas-ietf-network-slice-nbi-yang: AC provisioning vs. 
(slice) service provisioning

Hi all,

(ccing OPSAWG as the generic AC work may belong there)

draft-ietf-teas-ietf-network-slice-nbi-yang includes some very few details 
about ACs, but those details can be hardly useful to actually provision ACs. 
Assuming that ACs will be created by "some magic" is not helpful either.

An approach to address this issue, not only for the slice service case but for 
other services, is to separate the provisioning of the ACs (as a service) vs. 
advanced service provisioning. draft-boro-opsawg-teas-attachment-circuit 
proposes a new service module managing ACs: ac-svc (see below). A slice service 
request can simply include references to ACs that were requested using the 
ac-svc model. Given that multiple SAPs can be bound to the same AC, it is also 
envisaged that multiple peer-sap-ids can be indicated in a request.

This approach has also the merit to simplify the slice service model as it will 
focus