Subject: [Gen-art] Genart last call review of draft-ietf-mpls-base-yang-15

From: Gyan Mishra via Datatracker <[email-masked]>
Date: Thu, 20 Aug 2020 13:21:12 -0700

Reviewer: Gyan Mishra
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-base-yang-??
Reviewer: Gyan Mishra
Review Date: 2020-08-20
IETF LC End Date: 2020-08-19
IESG Telechat date: Not scheduled for a telechat

Summary:
The draft is well written and provides a very basic augmentation of the Yang
core data modeling for routing management (NDMA) defined in RFC 8349 which
provides the framework for managing routing subsystems. This drafts provides a
new MPLS base model framework for managing MPLS routing subsystems, reflecting
the mpls protocol specifications defined in RFC 3031  for future extensibility
to Segment Routing architecture RFC 8200 and beyond.

Major issues:
The base mpls model defined in very BASIC as defined in the draft and does not
reflect the data modeling of all attributes and features of the MPLS
architecture defined in RFC 3031.  I understand this draft defines the topmost
transport label for MPLS forwarding however it does not fully represent all
data models representing the LDP protocol.

If the goal of this draft is to reflect RFC 3031 in its entirety it does not
appear to do so.  If the goal of the draft is to provide just the basics of the
MPLS address family framework for future extensibility for MPLS specification
as well and this draft is not the "end all be all" for the MPLS protocol
specification and is just an introduction of the mpls base Yang model then I
think this draft is ready for publication.

Examples what I believe is missing in defining RFC 30301 in this MPLS base 
Yang model. Defining the Label stack and depth of the stack Since this topmost
MPLS label can be LDP, Static or RSVP data model is mentioned but not in the
context of label stack with multiple lables and that the topmost label based on
LFIB forwwarding table could be either TE or LDP tompost label.

Also mention of BOS -Bottom of Stack bit for the label stack.

Implicit null label value 3 & Explicit Null  label value 0 & QOS related to EXP
marking related to uniform & pipe mode. I did not see any mention of EXP bits.

Also LDP Downstream on demand versus Downstream unsolicited label distribution
method MPLS LIB and FEC binding for LSP  and data structure for LFIB entry
local label & remote label learned via label mapping message.

LDP label advertise, allocate, accept policy for /32 FEC binding to be only the
loopback of iBGP peer FEC Destination.

Label Imposition, Label Swapping & Label Disposition.

MPLS LDP   multicast extension mLDP - P2MP LSP

Also BGP LU labeled unicast BGP being used for Label distribution and label
binding for inter-as for topmost label binding inter-as stitching RFC 8277.

Also context related to LDPv6 RFC 7552.  Also softwire mesh framework RFC 5565
v6 edge over v4 core or v4 edge over v6 core and core transport being v4 or v6
and not both.

Minor issues:
None

Nits/editorial comments:
The draft is well written and serves a critical need to extend the Yang data
modeling capabilities from existing IPv4 & IPv6 address families to MPLS
address family framework. A XML file was not provided on the datatracker so I
was not able to run idnits against the draft.

---

From: Tarek Saad <[email-masked]>
Date: Fri, 21 Aug 2020 19:37:07 +0000

Hi Gyan,

Thanks for your review and feedback. Please see inline for response.

On 8/20/20, 4:21 PM, "Gyan Mishra via Datatracker" <[email-masked]> wrote:

    [External Email. Be cautious of content]

    Reviewer: Gyan Mishra

    <https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!S8w6fBzg5hjb7UcNsQdv20qrXxR22KyMBmCTkOJGQW6T-3ejGFC0tAbCed7y0Q$ >.

    Summary:

    Major issues:

[TS]: Yes, the MPLS base model is agnostic to the signaling protocol that used to populate the MPLS RIBs. As illustrate in Figure 1, we expect other models to be augmenting MPLS base model.

[TS]: Yes, this model serves as base augmentation for other MPLS models.

    Also mention of BOS -Bottom of Stack bit for the label stack.
[TS]: The MPLS label stack type is defined in RFC8294 (see rt-types:mpls-label-stack) and is being used by MPLS base model.

[TS]: these types are all are already defined in RFC8294 (please refer to traffic-class instead of EXP). See below:
    +--ro mpls-label-stack
          +--ro entry* [id]
             +--ro id               uint8
             +--ro label?           rt-types:mpls-label
             +--ro ttl?             uint8
             +--ro traffic-class?   uint8

    Also LDP Downstream on demand versus Downstream unsolicited label distribution
[TS]: As mentioned, these are outside the scope of this model.

    Also context related to LDPv6 RFC 7552.  Also softwire mesh framework RFC 5565
    v6 edge over v4 core or v4 edge over v6 core and core transport being v4 or v6
    and not both.
[TS]: MPLS bindings (local/remote) for V4 and V6 prefixes will be found in the augmentation of entries of the respective IPv4 and IPv6 RIBs defined in RFC 8349.

Regards,
Tarek (on behalf of co-authors)

    Minor issues:
    None

    Nits/editorial comments:

Juniper Business Use Only

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Aug 2020 15:46:38 -0400

Thanks Tarek

I am all set with your responses which I figured the draft  was a generic
framework for future MPLS models.

Thanks

Gyan

On Fri, Aug 21, 2020 at 3:37 PM Tarek Saad <[email-masked]> wrote:

>     <
> https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!S8w6fBzg5hjb7UcNsQdv20qrXxR22KyMBmCTkOJGQW6T-3ejGFC0tAbCed7y0Q$
> >.
>
>
>
> [TS]: Yes, the MPLS base model is agnostic to the signaling protocol that
> used to populate the MPLS RIBs. As illustrate in Figure 1, we expect other
> models to be augmenting MPLS base model.
>
>
>
> [TS]: The MPLS label stack type is defined in RFC8294 (see
> rt-types:mpls-label-stack) and is being used by MPLS base model.
>
>
>
> [TS]: these types are all are already defined in RFC8294 (please refer to
> traffic-class instead of EXP). See below:
>
>     +--ro mpls-label-stack
>
>           +--ro entry* [id]
>
>              +--ro id               uint8
>
> [TS]: MPLS bindings (local/remote) for V4 and V6 prefixes will be found in
> the augmentation of entries of the respective IPv4 and IPv6 RIBs defined in
> RFC 8349.
>
>
>
> Regards,
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD