Re: [OPSAWG] WG LC: L3NM [and vpn-common documents]

[[e-mail]]

Hi Adrian, 

Thank you for the careful review. 

Almost all your comments are addressed in https://tinyurl.com/l3nm-latest. 

I agree to replace the reference to ns-definition I-D with a pointer to ns-framework, but I don't know what happens with the xml2rfc when I make the change. Will fix that one both in the L3NM and the common I-D.  

I created an issue for the slaac comment (https://github.com/IETF-OPSAWG-WG/lxnm/issues/261). Will address that one in the same time that we are dealing with how to craft an IPv6-only L3NM config (a first proposal from Paul with some feedback can be seen at https://github.com/IETF-OPSAWG-WG/lxnm/issues/225).

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[e-mail]] De la part de Adrian
> Farrel
> Envoyé : samedi 27 mars 2021 16:35
> À : [e-mail]
> Cc : 'Joe Clarke (jclarke)' <jclarke=[e-mail]>
> Objet : Re: [OPSAWG] WG LC: L3NM [and vpn-common documents]
> 
> Hi,
> 
> WGLC review of draft-ietf-opsawg-l3sm-l3nm-07
> 
> I've reviewed this document a couple of times as it was being made,
> and I have attended a few of the design team calls mainly as a
> spectator. I co-chaired the L3SM working group so I have some clue as
> to what is going on. I'm working with some of the authors on the EU-
> funded Teraflow project where we are putting together a top-to-bottom
> YANG-based management system and where the L3NM function is clearly
> needed.
> 
> As part of working group last call I've had another look at the draft
> and I conclude it is ready for publication.
> 
> It may be worth explicitly notifying the BESS working group during
> IETF last call to ensure adequate review from L3VPN experts.
> 
> There are some minor points below.
> 
> Best,
> Adrian
> 
> ===
> 
> 1.
> 
> s/used to fed/used to feed/
> 
> ---
> 
> 4.
> 
> I think that [I-D.ietf-teas-ietf-network-slice-framework] is a better
> reference than [I-D.ietf-teas-ietf-network-slice-definition].  The
> latter is due to be merged into the former, so in time only the
> former will contain useful material.
> 
> ---
> 
> 5.
> 
> s/Such view is only/Such a view is only/ s/a L3SM template/an L3SM
> template/ s/A L3VPN involves/An L3VPN involves/ s/represented as
> using/represented using/
> 
> ---
> 
> 6.1
> 
> OLD
>    Also common addition and/or removal of sites of an existing
> customer
>    VPN can benefit of using L3NM by creation of workflows that either
>    prune or add nodes as required from the network data mode.
> NEW
>    A common additional function for VPNs is the addition or removal
> of
>    customer sites.  Workflows can use the L3NM in these scenarios to
>    add or prune nodes from the network data model as required.
> END
> 
> ---
> 
> 6.2
> 
> s/manage to avoid asymmetric/managed to avoid asymmetric/ s/usage of
> unavailable/use of unavailable/
> 
> ---
> 
> 7.2
> 
> s/scheme(s)/schemes/
> 
> ---
> 
> 7.5
> 
> s/enable a VPN network access/enables VPN network access/ s/values
> are defines defined in/values are defined in/
> 
> ---
> 
> 7.5
> 
> OLD
>    'router-id':  Indicates a unique Router ID information.  It can be
> an
>       IPv4 or IPv6 address as a function of the enclosed address-
> family.
> NEW
>    'router-id':  Indicates a unique Router ID.  It can be either an
> IPv4
>       IPv6 address as a function of the setting of 'address-family'.
> END
> 
> ---
> 
> 7.5
> 
>    'maximum-routes':  Indicates the maximum prefixes that the VPN
> node
>       can accept for a given address family and routing protocol.  If
>       'protocol' is set to 'any', this means that the maximum value
>       applies to any active routing protocol.
> 
> To check that you mean "any". That is, the maximum applied to each
> protocol individually. You would be better to use "each".
> Or you may mean "all". I.e., the maximum applies to the sum of all
> protocols. You would be better to use "applies as a total across all"
> 
> ---
> 
> 7.6.1
> 
> s/a L3VPN/an L3VPN/
> 
> ---
> 
> 7.6.2
> 
> s/or both information/or both/
> 
> ---
> 
> 7.6.2
> 
>    Figure 11 shows the structure of the dynamic IPv4 address
> assignment.
> and
>    Figure 12 shows the structure of the dynamic IPv6 address
> assignment.
> 
> Is the word "dynamic" wrong here as the options include "static"?
> 
> ---
> 
> 7.6.2
> 
> I expected Figure 12 to show provider-dhcp-slaac and slaac
> 
> ---
> 
> 7.6.3
> 
> s/route(s)/routes/
> s/base that make use of/base that makes use of/ s/IP address(es)/IP
> addresses/ s/route(s)/routes/
> 
> ---
> 
> 7.6.3
> 
> OLD
>          'warning-threshold':a warning
>          notification will be triggered'
>       A warning notification is triggered when this limit is reached.
> NEW
>          'warning-threshold': A warning notification is triggered
> when
>             this limit is reached.
> END
> 
> ---
> 
> 7.7
> 
> s/will have an effect to disable/will have the effect of disabling/
> s/Global data nodes/global data nodes/   ??
> s/Except the 'status' node/Except for the 'status' node/
> 
> ---
> 
> 8.
> 
> leaf default-route
>    s/route(s)/routes/  (twice)
> 
> -----Original Message-----
> From: OPSAWG <[e-mail]> On Behalf Of Joe Clarke
> (jclarke)
> Sent: 22 March 2021 13:32
> To: [e-mail]
> Subject: [OPSAWG] WG LC: L3NM and vpn-common documents
> 
> Hello, WG.  One of the action items out of the 110 meeting was to put
> the L3NM (https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-07)
> and vpn-common
> (https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03)
> documents through WG LC.  The authors have said that these can work
> independently from the L2NM document, which is still being revised.
> 
> This begins a two-week WG LC for these two documents.  Please provide
> your comments and concerns by April 5, 2021.  Additionally, if anyone
> is interested in acting as shepherd for either of these documents,
> please let the chairs know.
> 
> Thanks.
> 
> Joe
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.