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 <ts...@juniper.net> 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" <nore...@ietf..org> > 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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
