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

From: Dhruv Dhody <[email-masked]>
Date: Mon, 5 Apr 2021 23:46:34 +0530

Hi WG,

I support publication for both the I-Ds. Some minor comments -

==
General:
- I guess the best practice for a section in the reference is "RFC
YYYY: The title, Section X" instead of "Section X of RFC YYYY"
- Both YANG modules could use more references (Example multicast part in L2NM)
==
draft-ietf-opsawg-vpn-common:
- Not sure about the difference between the identity "sr-mpls" and "sr-te".
- Is there a reference for QinAny? Also, should we use 'QinQ' and
'QinAny' in the description, instead of 'qinq' and 'qinany'?
- Some of the references used in YANG are not listed in Section 9.
Example - IEEE Std 802.1Q, RFC 8453.
==
draft-ietf-opsawg-l3sm-l3nm:
- For leaf vpn-type, should we check that it is set to L3VPN in the YANG?
- For identity provider-dhcp-slaac, should we add if-feature vpn-common:ipv6.
- typedef area-address is not used, yang:dotted-quad is used for isis
which i think is incorrect. I suggest to use isis:area-address for
ISIS and ospf:area-id-type for OSPF for the respective YANG modules.
- Why is the vpn-node-id a union for string or uint32? This is not
done for any other identifier, only vpn-node-id...
- leaf key for BGP
(/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-network-accesses/vpn-network-accesse/routing-protocols/routing-protocol/bgp/security/keying-material/key)
has an incorrect description as - "OSPF authentication key."
- Maybe the keying-material should be under NACM?
- s/nontrollers/controllers/g
==

Thanks!
Dhruv

On Mon, Mar 22, 2021 at 7:02 PM Joe Clarke (jclarke)
<jclarke=[email-masked]> wrote:
>
> 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: Wed, 7 Apr 2021 07:53:00 +0000

Hi Dhruv, 

Thank you for the review. 

> - Not sure about the difference between the identity "sr-mpls" and

Med: sr-mpls refers to RFC 8660, which states that TE is out of scope: 
    
   The case where the outgoing label is not the top
   label and is part of a stack of labels that instantiates a routing
   policy or a traffic-engineering tunnel is outside the scope of this
   document and may be covered in other documents such as
   [ROUTING-POLICY].

sr-te refers basically to RFC8426.

References for both are provided in the module.  

> - Is there a reference for QinAny?

Med: We failed to find a satisfying authoritative reference.

 Also, should we use 'QinQ' and
> 'QinAny' in the description, instead of 'qinq' and 'qinany'?

Med: Fixed. 

> Example - IEEE Std 802.1Q, RFC 8453.

Med: Fixed. Adding those has a side effect to call them out in the core text. Some text rearrangement was needed as you can see at: https://github.com/IETF-OPSAWG-WG/lxnm/commit/52e9a191b7adb3f8e90f6cf404518ef078dd1093.  

Cheers,
Med 

_________________________________________________________________________________________________________________________

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 7 Apr 2021 15:57:30 +0530

Hi Med,

> sr-te refers basically to RFC8426.
RFC 8426 does not look like the correct reference. It does not have a term
called SR-TE.

Also, the quoted text above from RFC8660 is about the forwarding behavior
for Global SIDs. Moreover from the VPN point of view, do we need to
distinguish between the use of a single global SID v/s a stack? Not sure.

I thought maybe we use the term SR-policy but that is applicable for both
SR-MPLS and SRv6. Thus not sure about it.

> Med: We failed to find a satisfying authoritative reference.
Same here! :(
Could the IEEE liaison help, or is it a lost cause!

> Med: Fixed. Adding those has a side effect to call them out in the core
> text. Some text rearrangement was needed as you can see at:
> https://github.com/IETF-OPSAWG-WG/lxnm/commit/52e9a191b7adb3f8e90f6cf404518ef078dd1093.
>
>
>
Some like to put a table of all references used in the YANG model in the
core text to make this exercise easier :)

Thanks!
Dhruv

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 7 Apr 2021 14:48:16 +0000

Re-,

After re-reading 8426, I think that you have a valid point. I went through the bunch of SPRING documents, but unless I’m mistaken none of them formally defines SR-TE.

The initial intent was to control the policy to build the underlay when SR is used: indicate that a TE topo is needed to run SR. That’s said, if any advanced policy instruction is needed in addition to SR, this can be handled as part of the service mapping I-D.

Will remove sr-te from the draft. Thank you for pointing this.

Cheers,
Med

De : Dhruv Dhody [mailto:[email-masked]]
Envoyé : mercredi 7 avril 2021 12:28
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]; Joe Clarke (jclarke) <jclarke=[email-masked]>
Objet : Re: [OPSAWG] WG LC: L3NM and vpn-common documents

Hi Med,

On Wed, Apr 7, 2021 at 1:23 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv,

RFC 8426 does not look like the correct reference. It does not have a term called SR-TE.

Also, the quoted text above from RFC8660 is about the forwarding behavior for Global SIDs. Moreover from the VPN point of view, do we need to distinguish between the use of a single global SID v/s a stack? Not sure.

I thought maybe we use the term SR-policy but that is applicable for both SR-MPLS and SRv6. Thus not sure about it.

Same here! :(

Med: Fixed.

Some like to put a table of all references used in the YANG model in the core text to make this exercise easier :)

Thanks!
Dhruv

Cheers,
Med

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 8 Apr 2021 13:17:52 +0000

We are concluding the WG LC for this document.  All of the IPR responses
have been received (no IPR has been disclosed), and the LC precipitated
a number of comments.  The vpn-common module has just been updated, and
there looks to be a pending L3NM update.

As Adrian mentioned, he graciously stepped up to be shepherd of both
L3NM and vpn-common.  Thank you, Adrian.

I will mark the vpn-common document as pending write-up and the L3NM as
pending a revised I-D.

Thanks to the WG (and our expert reviewers) that have helped shore up
these documents.

Joe

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 8 Apr 2021 14:06:12 +0000

Hi Joe/team,

I reviewed the L3NM document and created issues 266, 267, 268 and 269 to  the GIT repository.

- L3NM: Adding leaf for vlan virtual interface id
- L3NM: Missing BGP update source for BGP clients
- L3NM: BGP client, redistribute connected ipv4 / ipv6 addresses
- L3NM: Multi-hop clients, enabling/disabling mpls label re-write

Regards,
Roque

On 08.04.21, 15:18, "OPSAWG on behalf of Joe Clarke (jclarke)" <[email-masked] on behalf of jclarke=[email-masked]> wrote:

    Joe

---

From: tom petch <[email-masked]>
Date: Thu, 8 Apr 2021 16:11:29 +0000

From: OPSAWG <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Sent: 07 April 2021 11:27

One comment on sr-te inline under <tp>

Hi Med,

> - Not sure about the difference between the identity "sr-mpls" and

<tp>

sr-te is used in the te world.  There is even an I-D all about it,
draft-ietf-teas-yang-sr-te-topo

te has presence containers (not identity) for the different topologies and so defines one for sr-mpls; no need to specify te in that, te can be taken for granted in this WG!

May be one day OPSAWG and TEAS will overlap and more will be needed:-)

Tom Petch

Same here! :(

Med: Fixed.

Thanks!
Dhruv

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 9 Apr 2021 07:42:38 +0000

Hi Dhruv, 

(Focusing the L3NM part)

We made changes to address almost all your suggestions. 

No changes are made for two of your comments for reasons that we detailed in  https://github.com/IETF-OPSAWG-WG/lxnm/issues/263. Can you please check and let us know if that is OK with you. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Dhruv
> Dhody
> Envoyé : lundi 5 avril 2021 20:17
> À : Joe Clarke (jclarke) <jclarke=[email-masked]>
> Cc : [email-masked]
> (/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-network-
> accesses/vpn-network-accesse/routing-protocols/routing-
> protocol/bgp/security/keying-material/key)

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 9 Apr 2021 14:01:50 +0100

Hi,

You all might like to look at draft-ietf-teas-rfc3272bis

That's a long document, and although any review would be very much welcomed,
the key is to look at the "components" of TE as discussed in section 1.2:
policy path steering, and resource management. It is "helpful" to describe
something as TE only when all elements are present, and to use the names of
the components when they are not all in use.

4.1.16 of draft-ietf-teas-rfc3272bis is specifically about SR

Comments on draft-ietf-teas-rfc3272bis could usefully be directed to the
TEAS list.

Cheers,
Adrian
-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of tom petch
Sent: 08 April 2021 17:11
To: Dhruv Dhody <[email-masked]>; [email-masked]
Cc: [email-masked]; Joe Clarke (jclarke)
<jclarke=[email-masked]>
Subject: Re: [OPSAWG] WG LC: L3NM and vpn-common documents

From: OPSAWG <[email-masked]> on behalf of Dhruv Dhody
<[email-masked]>
Sent: 07 April 2021 11:27

Hi Med,

On Wed, Apr 7, 2021 at 1:23 PM
<[email-masked]<mailto:[email-masked]>> wrote:
Hi Dhruv,

<tp>

te has presence containers (not identity) for the different topologies and
so defines one for sr-mpls; no need to specify te in that, te can be taken
for granted in this WG!

Tom Petch

Same here! :(

Med: Fixed.

Med: Fixed. Adding those has a side effect to call them out in the core
text. Some text rearrangement was needed as you can see at:
https://github.com/IETF-OPSAWG-WG/lxnm/commit/52e9a191b7adb3f8e90f6cf404518e
f078dd1093.

Thanks!
Dhruv

Cheers,
Med

____________________________________________________________________________
_____________________________________________

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.