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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> Thanks for your review and feedback. Please see inline for response.
>
>
>
> On 8/20/20, 4:21 PM, "Gyan Mishra via Datatracker" <[e-mail]>
> wrote:
>
>
>
>     [External Email. Be cautious of content]
>
>
>
>
>
>     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://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!S8w6fBzg5hjb7UcNsQdv20qrXxR22KyMBmCTkOJGQW6T-3ejGFC0tAbCed7y0Q$
> >.
>
>
>
>     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.
>
>
>
> [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.
>
>
>
>     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.
>
>
>
> [TS]: Yes, this model serves as base augmentation for other MPLS models.
>
>
>
>     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.
>
> [TS]: The MPLS label stack type is defined in RFC8294 (see
> rt-types:mpls-label-stack) and is being used by MPLS base model.
>
>
>
>     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.
>
>
>
> [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.
>
>
>
>     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.
>
> [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:
>
>     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.
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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