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

Alissa Cooper <alissa@cooperw.in> Thu, 10 September 2020 00:40 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B469F3A0975; Wed, 9 Sep 2020 17:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=UgZo2Af/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C8pZq08/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UuLCvRGmDii; Wed, 9 Sep 2020 17:40:42 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4E43A0976; Wed, 9 Sep 2020 17:40:42 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8CFF05C013F; Wed, 9 Sep 2020 20:40:41 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 09 Sep 2020 20:40:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=AysSWq9EuAEdLz2Qj0g7H9U zG8q4Hl1Ey2+P5CimgEI=; b=UgZo2Af/UWdLjfxaK4L05Qd/kU31QEiOnVTCudY I+023FvCChbkUzy2JZV12jvtFxMdja+FvfMjrdbXzWx/aPueVba+aKS9p1ffovVg 0yKzBZgzTHnjsZRz/Apxv6ln2wF5Aver0hKH9QVaAqmZe7ExM6vxuD6pCyFngVXh CdiHrS2K4joAicetkZvaEx4E+fbMiK25m3yERIr2UtII6Kj7bGTzPvqLhd2aWbIv Ovuftull4QlqCYJa2CZKCdGEGdT6BwiSFdd9+lfB4oqCAdDnmUctdHzGTvLxAAdC DGS6n8YNXx1c/N0SUWIgs9W2xAPDm7NxCtnzVd7QlP/0/8A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=AysSWq 9EuAEdLz2Qj0g7H9UzG8q4Hl1Ey2+P5CimgEI=; b=C8pZq08/XZS1CXFXbe/td9 GdJw7ECyllBjG0joQiS3rzJsXiv8zw6VtL+LbdEjKjJW5nQ766F2xmQXNLH+UcyI 9S3seKwiGGMfg0ftmbFTnoWQVDE7HdRIAJjU/640A9JXN1S11sMecB1LlbGNAld8 NmDte48AaOW52DhF2XATGo8SA6Nl/Z9RfYKCUNdkWrNheZG1ty111roXg/yzk0zo q4/PC5WvEmz9c0M2uWxmnOVEk/7sXyHierLdO4tAok0tg6jWQTi+k4fGCgXKJgdh pbdtmy+ZIJVrBuSualo3g/+cb6bLoYVHO/Uo1qChcQv6QVAs64FxHp5110lWCZ3Q ==
X-ME-Sender: <xms:CXZZXzDLAWv-b2Lp5qNTaQAjrikeLIbdYzm4jIwn_DJUs1vFf59WUg> <xme:CXZZX5i_hmSW5nJS2ySzcdHP-I9hAWztX3h0dhqvZo-Me5swCEuWkhTEtNxAp3ljF uszv2P_ieuN-V6bsg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehiedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepvddtieeitedujeeiueekteduleeigeeiuefhudeghefghfduveettdeifeff heffnecuffhomhgrihhnpehurhhluggvfhgvnhhsvgdrtghomhdpvhgvrhhiiihonhdrtg homhdpihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeefnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtoh hophgvrhifrdhinh
X-ME-Proxy: <xmx:CXZZX-l7AkX6qtS8lfcjTijJqrdK-XK6pY0bR9Gt0htIunUnoBNMXA> <xmx:CXZZX1yEESsGZo0ecw2qG-7RTiS4jvK0up_zMU96ArTztuXgsqINUg> <xmx:CXZZX4THcxwRk0moOfpnEXCMCXP6K7DFRhzqgEwPkH0CoCZevExqvA> <xmx:CXZZX-e3GtkJGqrMBMPgnQdzY67xbkykqy4_GoVKidipX3Y9n_o1JQ>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id D4E70328005E; Wed, 9 Sep 2020 20:40:40 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <2E376E3C-6CB2-45BA-A3A9-01AAEF9F5984@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D450F14-C8BD-4589-AF77-AA5E68711E82"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 9 Sep 2020 20:40:40 -0400
In-Reply-To: <CABNhwV06pwCOh1BxqStVau+uKHqAW8N+x_OjRcnTKg=qofNJUg@mail.gmail.com>
Cc: Tarek Saad <tsaad@juniper.net>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-mpls-base-yang.all@ietf.org" <draft-ietf-mpls-base-yang.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
To: Gyan Mishra <hayabusagsm@gmail.com>
References: <159795487231.23645.8624000777631081432@ietfa.amsl.com> <D2B489A5-8ED3-4AA0-A213-217B4D32DDB9@juniper.net> <CABNhwV06pwCOh1BxqStVau+uKHqAW8N+x_OjRcnTKg=qofNJUg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/IDEoh1q6HGxQ1m_45zyLSJMbTTY>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mpls-base-yang-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 00:40:45 -0000

Gyan, thanks for your review. Tarek, thanks for your response. I entered a No Objection ballot.

Alissa


> On Aug 21, 2020, at 3:46 PM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> 
> 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 <tsaad@juniper.net <mailto:tsaad@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" <noreply@ietf.org <mailto:noreply@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$ <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 Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art