Re: [RTG-DIR] rtgdir Last Call Review of draft-ietf-opsawg-l2nm-10

[[e-mail]]

Hi Himanshu,

Many thanks for the review.

Please see inline.

Cheers,
Med

De : last-call <[e-mail]> De la part de Shah, Himanshu
Envoyé : vendredi 12 novembre 2021 00:33
À : [e-mail]; [e-mail]; [e-mail]
Cc : Joe Clarke (jclarke) <[e-mail]>; [e-mail]; LucAndré Burdet <[e-mail]>
Objet : [Last-Call] rtgdir Last Call Review of draft-ietf-opsawg-l2nm-10


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-opsawg-l2nm-10.txt
Reviewer: Himanshu Shah

Review Date: 11/11/2021

IETF LC End Date: not known
Intended Status: Standards Track



Summary:



Firstly, the review request was made for revision -06- of this document, but the latest revision is -10-.

So I took the liberty to review the latest version. The document is quite comprehensive with lots of details.

I was able to consult with some of the colleagues within my company to get network management perspective.

The review comments reflect the experiences of participants in this field. I believe this would be more

helpful to the authors.

[Med] Thanks.



The document is good candidate for publication, but the comments provided should be considered and addressed

before the publication.



Comments:



Note that I am not following the provided guidelines on the issue categories (Like major/minor). I leave that

upto AD and/or authors on what level of attention they would like to provide.



Overall:

-   Resiliency/Protection aspects of the requirements/modelling need more elaboration from the access/core/service perspective.



[Med] We have in the document a fair discussion about protection matters at the access part (including multihoming, EVPN) + dedicated appendices. The resilience at the core can be handled by providing some preference of the underly transport or invoke the draft-ietf-teas-te-service-mapping-yang-09.html#name-l2nm:


module: ietf-l2nm-te-service-mapping
  augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
            /l2vpn-ntw:vpn-service:
    +--rw te-service-mapping!
       +--rw te-mapping
          +--rw map-type?                  identityref
          +--rw te-policy
          |  +--rw color?               uint32
          |  +--rw protection-type?     identityref
          |  +--rw availability-type?   Identityref

We will add a clarification about this.



o   For example – PW protection

-   Topology types may need more clarity on what is the desired end result.

o   For example – Custom or Tree topologies – what are the forwarding rules at the VPN access points.

o   Is hierarchical VPLS (H-VPLS) a consideration and how is it expressed in the model?

[Med] A basic h-vpls configuration is supported. This can be done by t-ldp-pw-type to hvpls. Some dedicated data nodes can then be used when that type is used.



-   PW characteristics should be more abstract – seems more detailed in the document while still not covering

o   Protected?

o   MS-PW?

[Med] We don’t have explicit parameters to indicate this. Will think about this further. Thanks.



-   Service Status need more elaboration. Our experience has been challenging in this area and desire more details on

its usage/semantics (e2e service, vpn-node, vpn-access, etc).



[Med] Not sure which elaboration is needed, but will double check the text and update as appropriate.



Specifics (using -10- draft)

(Do note this is best effort comments – document is too long and not entire document is scanned with fine toothcomb) –



(page 14 – last but one paragraph)

  'bfd-profile-identifier':  A Bidirectional Forwarding Detection (BFD)

      profile refers to a set of BFD [RFC5880] policies that can be

      invoked when building a VPN service.



Himanshu> Should this be a OAM-profile to accommodate OAM other than BFD?

For instance, 802.1ag, Y.1731, etc.



[Med] We are not using a generic OAM profile here because we are trying to ease the mapping with the service model (RFC 8466), which defines a bd-profile. Note also that we are importing this from the vpn-common I-D, which is used for both L3 and L2 VPNs.



(page 17 – last para)



   'vpn-service-topology':  Indicates the network topology for the

      service: hub-spoke, any-to-any, or custom.



Himanshu> What about H-VPLS? Does that type of construct fall in to "custom"

[Med] hub-spoke will be OK for H-VPLS.



Himanshu> In Custom topology, how are forwarding rules specified??

[Med] I guess this is covered by this text from the vpn-common I-D, where “custom” is defined:



“The VPN topology is controlled by the import/export policies.”



Himanshu> What about resiliency, for example, primary/backup PW

[Med] This can be handled by means of, e.g., pw-priority. Please note that we can’t be exhaustive as we are already have a very long document. Augmentations can be added in the future to zoom on specific functionalities to the base module.



(page 18)

      l2tp-signaling':  The L2NM uses L2TP-signaled Pseudowires as

         described in [RFC6074].



Himanshu> What about static PWs? Multi-segment PWs?

[Med] Already clarified above.



(page 18)

   'underlay-transport':  Describes the preference for the transport

      technology to carry the traffic of the VPN service.  This

      preference is especially useful in networks with multiple domains

      and Network-to-Network Interface (NNI) types.  The underlay

      transport can be expressed as an abstract transport instance

      (e.g., an identifier of a VPN+ instance, a virtual network

      identifier, or a network slice name) or as an ordered list of the

      actual protocols to be enabled in the network.



      A rich set of protocol identifiers that can be used to refer to an

      underlay transport (or how such an underlay is set up) are defined

      in [I-D.ietf-opsawg-vpn-common].



Himanshu> Not clear how ordered list of transport work for VPN

Spanning multiple domain and how it is pinned for each domain..

[Med] This can be handled/passed by domain-specific controllers, for example. More advanced service mapping policies are discussed in draft-ietf-teas-te-service-mapping-yang-09#section-6.3.2.



(page 23)

         'protection-type':  It defines the protection type



Himanshu> Not sure what protection-type means for MAC-loop-prevention

[Med] This identifies the loop prevent type (e.g., shut, trap, etc.). “prevention-type” would be more appropriate but we are using the same name as in the L2SM (RFC8466) to ease the mapping with the service model. Updated the description to: “It defines the loop prevention type (e.g., shut).”



(page 33)

   The VPN network access is comprised of:



   'id':  Includes an identifier of the VPN network access.



Himanshu> Should there be a "name" field as well - keeping with same pattern of identification (id, name, description)

[Med] We could … but we didn’t as we are trying to keep a similar structure for both L3NM and L2NM.



(page 33)

   'port-id':  Indicates the port on which the VPN network access is

      bound.

Himanshu> Text above says - interface-id and not port-id.

[Med] Fixed. Thanks.



 Irrespective, does interface-id refer to

or include "attachment-circuit"



[Med] Yes.



(page 34)

   'status':  Indicates the administrative and operational status of the

      service.

Himanshu> Perhaps refers to status of the access-point and not global VPN service, right?



[Med] I confirm. Fixed.



Thanks,
Himanshu


_________________________________________________________________________________________________________________________

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.