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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Mar 2021 15:34:56 -0000

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 <[email-masked]> On Behalf Of Joe Clarke (jclarke)
Sent: 22 March 2021 13:32
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Mon, 29 Mar 2021 06:27:23 +0000

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:[email-masked]] De la part de Adrian
> Farrel
> Envoyé : samedi 27 mars 2021 16:35
> À : [email-masked]
> Cc : 'Joe Clarke (jclarke)' <jclarke=[email-masked]>
> Objet : Re: [OPSAWG] WG LC: L3NM [and vpn-common documents]
> 
> Hi,
> 
> 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.
> 
> It may be worth explicitly notifying the BESS working group during
> IETF last call to ensure adequate review from L3VPN experts.
> 
> 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
> 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
> 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
> (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.
> 
> 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
> 

_________________________________________________________________________________________________________________________

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.