From nobody Sun Jul 16 03:43:06 2023 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45255C15154D for ; Sun, 16 Jul 2023 03:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10tudeyIBNZY for ; Sun, 16 Jul 2023 03:43:01 -0700 (PDT) Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.151.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079A0C15154A for ; Sun, 16 Jul 2023 03:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1689504179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LOOQfikn7ByYd9R53AHMX+Cx9SnMI6ObwxtuTDihQSY=; b=ssxwuNTEiZXqKPxJbTCu70EE2MF+9kgzgwvrb6FW4s8HSrshTkWgCerK8ZCx9LqaEuWLMt uopcLL7wEUeVLt+l2tyJBVdymRg4eh6b0ciMt9QcJOaORJjAvUln668eI9+yopgz+H2vau cWUhPOZlgx518/aDweAnTe8ILumTWxI= Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-31-q2b4pVa8NOWAcv6owEyWPw-1; Sun, 16 Jul 2023 03:42:51 -0700 X-MC-Unique: q2b4pVa8NOWAcv6owEyWPw-1 Received: from CO6PR03MB6290.namprd03.prod.outlook.com (2603:10b6:5:357::20) by LV8PR03MB7424.namprd03.prod.outlook.com (2603:10b6:408:192::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.27; Sun, 16 Jul 2023 10:42:44 +0000 Received: from CO6PR03MB6290.namprd03.prod.outlook.com ([fe80::429f:82be:a302:7517]) by CO6PR03MB6290.namprd03.prod.outlook.com ([fe80::429f:82be:a302:7517%6]) with mapi id 15.20.6588.031; Sun, 16 Jul 2023 10:42:42 +0000 From: Alexander Vainshtein To: "Matthew Bocci (Nokia)" CC: "rtg-dir@ietf.org" , "mpls@ietf.org" , MPLS Working Group , "draft-ietf-mpls-mna-requirements.all@ietf.org" Thread-Topic: RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05 Thread-Index: Admv1HMd9b2uasifTCettGEDm3ixvwGjGpRlAFr1I4A= Date: Sun, 16 Jul 2023 10:42:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CO6PR03MB6290:EE_|LV8PR03MB7424:EE_ x-ms-office365-filtering-correlation-id: 15abb97c-6807-4df2-a86c-08db85e961d6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: ca2yOd5NQYGXi0rRF9wRjOAL0t/nG1QfW6tUUeEgdExU8rw8ItckGD3NFWxAyUIFtVDsCU0gv/Cdwjf9eAua0u/jYTHFg5S8J8pn+H4rRUAF5KH1YASYLqAxMnVREy5zdw5/tYt5g+Hfs11NQxYOO5hZa5HRHaxWyPcbauilUyn/tLQg7WtkkE8ThKqfXlerk/f9ADuaDyhHFJhKUMXkxESIg8HRQzUB+4zD5yGJGpsukgO6jKb1t55J89gJm4P9xLQTkwIRheNGA0aFw3Bnl8e7TClTtMrzhvr0QRiWIJ5ALgfetbchOD/MNXX2kd/K4aFQaJmtZxXVu2ycsqgOrvSK9YcO4J5wpA2Ok2R0FuDZ2cHJDByngcIxAVFB2FmzCVoKuzaoWOGDwL+OVb4I27rGu5kwcLn8TPDxkeffZZ3j3umO3YyDQoh6c4AFAIjzCfjkJIA0y89SL5Ta7Ol7dOxMrTcjXzsXZgYcIIAQ9HYRdmAIcfk0+PUn0UDho2m4BlcOa+EkgoqxYodkKMiigyZpWxx3GbJyqIlDwwmfsYRTgwz4jQZAI+KuyHqLkGbStURthO2DKmn+aSQX7AdgRhXqY7NCjiiozZowJE0QY0I= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR03MB6290.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(396003)(136003)(39860400002)(376002)(366004)(451199021)(7696005)(33656002)(186003)(83380400001)(966005)(9686003)(26005)(6506007)(53546011)(71200400001)(64756008)(66556008)(66946007)(66446008)(66476007)(6916009)(4326008)(76116006)(478600001)(166002)(54906003)(122000001)(316002)(296002)(38070700005)(41300700001)(52536014)(38100700002)(5660300002)(8936002)(8676002)(86362001)(2906002)(30864003)(55016003)(559001)(579004); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?OvY9W+iexyImAA68Lsi9VnJWmuE7JE5CY5GkUBpr+0LW7GwWYx5iyCj1b3Iw?= =?us-ascii?Q?80Qik5RmyaeJLuNwGOgNfBLerovtSowQGFFZNIjfRgWAQks2P+yZXJu7inZT?= =?us-ascii?Q?Sf05ALQy+UMIBcwPWaHAtB4NrNXE4T4m9BEQCIz8bYLA2xjwdG2i+z7M4ZVU?= =?us-ascii?Q?a/T95XDQlvcOxGZtkjjaSyXAZgcOaH3YI1Pk3zZjcae1dirXJUOCux1OMnE4?= =?us-ascii?Q?fho9RjC4EPLRYk74IrrBBtyXSD4zWrwgAhRTTGvH2G1S2CojrHTmYM/uR0It?= =?us-ascii?Q?VLbM3YThJAh5xTxeNuP0XGjHkg73txsn/c6YhzuvGLRBcNW9OlhF94ObX9a4?= =?us-ascii?Q?QOgCuhDU3mGJnJgABgzth0YFTeEyppdaDe4ig3vS8jCqFyu851tNm8CN9lcm?= =?us-ascii?Q?OroMT/k4JQlCPuY/sJGw2BDoOReynQkduRl8CZKUTkRgiAqlsiDNZO1MpHwk?= =?us-ascii?Q?XUWQuFD8+j5R8x2b4MTat8iGMOBKfr9Va5htYGG9Uq3ZIbR1aipyrPuKiXLX?= =?us-ascii?Q?sFE0dQDP8OZlgA2u1TTIgTKaL7r+AjXl1qhX1nZIHK9EDM/apbDSfgEF41q3?= =?us-ascii?Q?pIBs+2OsNddSMmRPt6CT0X5NhAylPrJCNmbOMK3pX0u6qkjbOnxn09OlXX3O?= =?us-ascii?Q?NUqaT0p7cY9mdCCBj3FxkGLua1Vsw7gX55JBMr/efnw5ZjuYr2NlxWOeCAg0?= =?us-ascii?Q?3Ry9t8slR3USd8MoMSqJdW2/62k6xnfNa2xLGgxh5yqp+/JVmwCdXHRgqs8F?= =?us-ascii?Q?Galysg56U12UDyyV/fe3BguoKXiynCc9gqo+KYFuJhzg81Gch5YjphPs5rKJ?= =?us-ascii?Q?yBezCckMMN9vI7vHaJldvwqTV7ZUFiA926tq6FYVBtwRubDGO8EvXapmJhkk?= =?us-ascii?Q?TtFadeDOLvNfCj4ul10asXk7pjHpTkEEKAIixSrZikSrAcp7ol+m9UtFd862?= =?us-ascii?Q?qj8yxYrx2F+yf2SSZKdDGPB3C0XNYK0Jot4m/ZoHEkxSdemrl5McKsnQ8d4T?= =?us-ascii?Q?MvHvUNTsJPV4xCBnreD0k1VM5xp+94wkeganer+55u6eJFVchwCiX1UDKpHo?= =?us-ascii?Q?2VVa0P7QG9YyjJ1MtS3oYI0MniqK9w4LlC7g2aoouMR3FeYyTajlpkASuggs?= =?us-ascii?Q?NFa6FMrWlAOIufWhNd/VBvKSM4RKbeYg+keenMJDfLAY5krDOPmtW/EaX2ui?= =?us-ascii?Q?rYtVcBCGyJhTiOfxXOWzjdb3bmobbhGUqgqXEtNZzQBxACtGXIaCmml+0B+0?= =?us-ascii?Q?m7qu3SSgnAe7CGZvfaj3a8mq1iAduOGMW8C5NBPC6FgVz+OELe018S0MqbGZ?= =?us-ascii?Q?k/WZM1yJ/NoDk80TQUTctsCzybqr8R/TpBY+i7Pl+KB4pgrRG0j51ylf0xM5?= =?us-ascii?Q?oUoJ/VU5b6tNUTocEv/oOBaIVV84E3ADAuzHQcTo3FuNjBy5jvLC1tpnSI8H?= =?us-ascii?Q?4y7dKvg5Ibr+XRz96Baq9ODVI8AgDXlxh/BoMgXCvEF/OxTM6XHTD8AzbnBW?= =?us-ascii?Q?y4aY/GokYvFsaHYEPPInFmwFVeBUDw/H0Ql552vCriuntI0S/au/aeriGGEn?= =?us-ascii?Q?QtNC20yriz33THZyB+8=3D?= MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR03MB6290.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15abb97c-6807-4df2-a86c-08db85e961d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2023 10:42:41.8017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +b1ipZNaK4UoFvVsbry8z02cD+HSR8kTSPcx9JmsCtoTMRpPsG4JmA2nltYZzyUQksxARwAak+V/pRaIHnGHLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7424 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CO6PR03MB6290EAAFE0CAD31CA412F575F63AACO6PR03MB6290namp_" Archived-At: Subject: Re: [RTG-DIR] RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2023 10:43:05 -0000 --_000_CO6PR03MB6290EAAFE0CAD31CA412F575F63AACO6PR03MB6290namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Mathew, Lots of thanks for a prompt response. Please see some comments inline below. Regards, Sasha From: Matthew Bocci (Nokia) Sent: Friday, July 14, 2023 5:53 PM To: Alexander Vainshtein ; MPLS Working Grou= p ; draft-ietf-mpls-mna-requirements.all@ietf.org Cc: rtg-dir@ietf.org; mpls@ietf.org Subject: [EXTERNAL] Re: RTG-DIR Early review: draft-ietf-mpls-mna-requireme= nts-05 Hi Sasha Thank you very much for your detailed review. Please see below for some responses, prefixed by MB>. Regards Matthew From: rtg-dir > o= n behalf of Alexander Vainshtein > Date: Thursday, 6 July 2023 at 07:41 To: MPLS Working Group >,= draft-ietf-mpls-mna-requirements.all@ietf.org > Cc: rtg-dir@ietf.org >, mpls@ietf.org > Subject: [RTG-DIR] RTG-DIR Early review: draft-ietf-mpls-mna-requirements-0= 5 Hello I have been selected to do a routing directorate "early" review of this dra= ft: draft-ietf-mpls-mna-requirements-05. The routing directorate will, on request from the working group chair, perf= orm an "early" review of a draft before it is submitted for publication to = the IESG. The early review can be performed at any time during the draft's = lifetime as a working group document. The purpose of the early review depen= ds on the stage that the document has reached. The draft in question is a WG document, has been adopted about 1 year ago a= nd is not yet in the WG Last Call. It has been extensively discussed in the= MPLS Open Design Team. I have asked Loa (who is the shepherd of this draft) for the reasons for an= d the purpose of this review, and he has said that the draft "is a going in= to the WGLC process, we want the comments early, i.e. before we start the = WGLC, after all it is supposed to be "early", after the WGLC is too late in= the process. Better to have the RTG Area Early comments fully available to= the WG during the WGLC ". For more information about the Routing Directorate, please see https://wiki= .ietf.org/en/group/rtg/RtgDir Document: draft-ietf-mpls-mna-requirements-05 Reviewer: Alexander ("Sasha") Vainshtein Review Date: 06-Jul-23. Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resol= ved before it is submitted to the IESG. Comments: The draft is well written and easy to read. As the title clearly states, this draft presents generic requirements that = should be met by any specific MPLS Network Actions (MNA) solutions. As a generic comment, I am not sure whether the IETF reserved terms for ind= ication of requirement levels can be used in an Informational document, thi= s is for the WG Chairs and ADs to decide. But I think that usage - or non-usage - of these terms should be consistent= in the document, and this condition is not met in this draft. MB> There is plenty of precedent for informational RFCs to contain RFC2119 = language, and speaking as a co-author it seems reasonable here when we are = setting out the requirements for protocol development. [[Sasha]] My point was not about usage or non-usage of RFC 2119 language in= Informational RFCs, but about consistency of their usage. It contains: - Requirements that use the reserved IETF keywords (e.g., "Any MNA s= olutions to these requirements MUST NOT restrict the generality of MPLS arc= hitecture") - Requirements that use the non-capitalized words that, in their cap= italized form, become the IETF keywords (e.g., "An MNA solution MUST respec= t the principle that Special Purpose Labels are the mechanism of las= t resort and therefore must minimize the number of new SPLs that are alloca= ted"). Having a mix of capitalized and non-capitalized terms in the same re= quirement looks problematic to me - Requirements that do not include any words that can be associated = with the IETF reserved keywords (e.g., "NAIs are normally inserted at LERs,= but MAY be processed at LSRs and LERs"). MB> I agree that one is unclear. I think where we are not with the solution= s, it would make sense to change 'normally' to MUST only be. SOme thing like "If NAIs a= re inserted in a label stack, they MUST only be inserted at the ingress LER for that label= stack, and they MAY be processed..." [[Sasha]] Looks fine to me. MB> I will look through and clean up the other cases where there could be a= mbiguity. [[Sasha]] OK I have sent my early comments to the draft authors, and they suggested that= these should be submitted as the RTG-DIR review without any private discus= sions. I am following this suggestion after adopting these comments to the = RTG-DIR Early review template format. MAJOR ISSUES: None found. MINOR ISSUES: 1. The draft mentions RFC 3031 and RFC 3032 as the referenc= es for the MPLS architecture, but it does not mention RFC 5331 that au= gments MPLS architecture with upstream-allocated labels, label context spa= ces and "context labels". Does this mean that MNA is expected to be incompa= tible with upstream-allocated labels and/or context label spaces? If yes, i= t would be nice to have this stated explicitly. MB> Agreed. I will add a reference. 2. Item #7 in Section 3.1 as well as items #2 and #3 in Section 3.4 s= eem to imply preference to Post-stack ancillary data vs. In-stack one. Is t= his really the intention? If not, please consider stating explicitly that t= hese requirements do not preclude usage of In-stack ancillary data. MB> I am not sure it says that, and if in-stack was not allowed then we wou= ld have a requirement that says so. Maybe what we could add "A solution MAY choose to use in-stack ancillary d= ata, or it MAY choose to use post-stack ancillary data." as a first requirement in 3.4? [[Sasha]] Please note that the first problematic (from my POV) item appears= in Section 3.1., so adding another requirement in Section 3.4 may be too l= ate. Any text that eliminates any suggestion of bias towards In-stack or Po= st stack ancillary date would do. 3. Section 3.9 of RFC 3031 states that "the processing is always base= d on the top label, without regard for the possibility that some number of = other labels may have been "above it" in the past, or that some number of o= ther labels may be below it at present". (This principle has been tweaked = when "context labels" have been introduced in RFC 5331.) IMHO and FWIW, it= would be useful to explain what should happen to this architectural princi= ple with regard to MNA. MB> That may be better suited to the framework draft. [[Sasha]] I assume this means the MNA Framework draft. If so then: * This document is not referenced in the draft under review, but the ne= ed to cross-check with the framework draft appears as an Editor's comment i= n Section 1.1. * After briefly looking up the framework document, it seems that this E= ditor's comment highly relevant. I have to admit that I have completely mis= sed this aspect in my original review. * The framework document explicitly states in Section 2.4 that "A netwo= rk action sub-stack should never occur at the top of the MPLS label stack".= This addresses (in a way) my original question but seems to be in contradi= ction with item#3 in Section 3.1 of the requirements draft. Spreading these= statements to two different documents looks problematic to me. 4. I suggest augmenting item #3 in Section 3.2 with a statement that = reuse of an already allocated SPL for MNA purposes would require its retire= ment and re-allocation in accordance with the process defined in RFC 7274. (This comment is based on the discussion of re-use of GAL for MNA in t= he early days of the MPLS Open Design Team). MB> I agree this is a useful clarification. 5. Do items#8 and #9 in Section 3.3 consider SR-MPLS as one of the re= levant control plane protocols? May I suggest that an explicit list of such= protocols be provided to avoid any possible misunderstandings? MB> No. SR-MPLS is not a control plane protocol, although it may use a cont= rol plane protocol. The control plane protocols that can signal MPLS labels= whether for segment routing or other cases that use an MPLS data plane inc= lude LDP, RSVP, BGP, ISIS, OSPF... and there are numerous out of band mecha= nisms for programing labels like SNMP, Netconf, etc. I do not think there i= s any need to define what we mean by control plane protocols in this draft. [[Sasha]] This is probably a misunderstanding, since my question was about = ISIS, OSPF and BGP extensions for SR-MPLS. It seems that you consider these= protocols as relevant for the purpose of items #8 and #9 in Section 3.3 - = and I am OK with this. 6. Item #12 in Section 3.3 states that "NAIs are normally inserted at= LERs ": a. As mentioned above,. this statement does not carry any IETF keywor= d (MUST or SHOULD) to indicate the requirement level b. I suspect that normality, like beauty, is in the eye of the behold= er. A more suitable wording could be "LSRs SHOULD NOT insert NAI" (or somet= hing like that) MB> See my response above. 7. Can you please clarify whether the requirement in item#10 of Secti= on 3.4 can be addressed by an LER that is a head-end of an SR Policy (RFC 9= 256) that uses Binding SIDs in its list of segments? a. Usage of Binding SIDs makes control over the depth of the label st= ack quite problematic for the head-end of an SR Policy b. Another case when such control is problematic is usage of TI-LFA or Segment Routing Micro-loop Avoidance= mechanisms. MB> I agree with you that this is a problematic case. Any inter-domain case= (which is a common application of BSIDS) or cases where the label stack is= expanded using SR policies with BSIDS is an issue. As are tunnel-in-tunnel= cases like LDP over RSVP/SR-TE, BGP-LU over RSVP/SR-TE, etc. I think the r= equirement is still valid, and we probably don't need to say anything more = in a requirements document. It is up to the solutions to solve the problem. [[Sasha]] Item #6 in Section 3.1 says: "Any MNA solution specification MUST= discuss the ECMP consequences of the design." I think that a similar stat= ement about the need to discuss consequences of technologies that increase = the depth of the label stack in a way that is not controlled by the ingress= LER for this stack would be very much in place. NITS: 1. The draft refers to draft-saad-mpls-miad-usecases for the description of new MPLS use cases (both in the Introd= uction and Background sections). According to the Datatracker this draft ha= s been replaced by the MNA Usecases draft that is= a MPLS WG document. IMHO the reference should updated accordingly. MB>Agreed 2. I did not run the ID Checker on the draft, so could have missed ot= her nits. MB> It passes. Hopefully, these notes will be useful. Regards, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon= Communications Inc. and its Affiliates that is confidential and/or proprie= tary for the sole use of the intended recipient. Any review, disclosure, re= liance or distribution by others or forwarding without express permission i= s strictly prohibited. If you are not the intended recipient, please notify= the sender immediately and then delete all copies, including any attachmen= ts. --_000_CO6PR03MB6290EAAFE0CAD31CA412F575F63AACO6PR03MB6290namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Mathew,

Lots of thanks for a prompt respons= e.

 

Please see some comments inline below.=

 

Regards,

Sasha

 

From: Matthew Bocci (Nokia) <matthew.bocci@nokia.com>
Sent: Friday, July 14, 2023 5:53 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; MPLS= Working Group <mpls-chairs@ietf.org>; draft-ietf-mpls-mna-requiremen= ts.all@ietf.org
Cc: rtg-dir@ietf.org; mpls@ietf.org
Subject: [EXTERNAL] Re: RTG-DIR Early review: draft-ietf-mpls-mna-re= quirements-05

 

Hi Sasha<= /p>

 

Thank you very much for you= r detailed review.

 

Please see below for some r= esponses, prefixed by MB>.

 

Regards

 

Matthew

 

From: rtg-dir <rtg-dir-bounces@ietf.org> on behalf of Alexander Vai= nshtein <Alexander.Vain= shtein@rbbn.com>
Date: Thursday, 6 July 2023 at 07:41
To: MPLS Working Group <m= pls-chairs@ietf.org>, draft-ietf= -mpls-mna-requirements.all@ietf.org <draft-ietf-mpls-mna-requirements.all@ietf= .org>
Cc: rtg-dir@ietf.org <rtg-dir@ietf.org>, mpls@ietf.org <mpls@ietf.org>
Subject: [RTG-DIR] RTG-DIR Early review: draft-ietf-mpls-mna-require= ments-05

 

Hello

I have be= en selected to do a routing directorate “early” review of this = draft: draft-ietf-mpls-mna-requirements-05.

 

The routing directorate will, on request from the working group cha= ir, perform an “early” review of a draft before it is submitted= for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a workin= g group document. The purpose of the early review depends on the stage that= the document has reached.

 

The draft in question is a WG document, has been adopted about 1 ye= ar ago and is not yet in the WG Last Call. It has been extensively discusse= d in the MPLS Open Design Team.

I have asked Loa (who is the shephe= rd of this draft) for the reasons for and the purpose of this review, and h= e has said that the draft “is a going into the WGLC process, we want the comments early, i.e.  before we st= art the WGLC, after all it is supposed to be "early", after the W= GLC is too late in the process. Better to have the RTG Area Early comments = fully available to the WG during the WGLC ”.

For more = information about the Routing Directorate, please see = https://wiki.ietf.org/en/group/rtg/RtgDir

 

Document:= draft-ietf-mpls-mna-requirements-05

Reviewer:= Alexander (“Sasha”) Vainshtein

Review Da= te: 06-Jul-23.

Intended Status: Informational

 

Summar= y:

I have so= me minor concerns about this document that I think should be resolved befor= e it is submitted to the IESG.

Commen= ts:

The draft= is well written and easy to read.

As the ti= tle clearly states, this draft presents generic requirements that should be= met by any specific MPLS Network Actions (MNA) solutions.<= /p>

As a gene= ric comment, I am not sure whether the IETF reserved terms for indication o= f requirement levels can be used in an Informational document, this is for = the WG Chairs and ADs to decide.

But I thi= nk that usage – or non-usage – of these terms should be consist= ent in the document, and this condition is not met in this draft.

MB> There = is plenty of precedent for informational RFCs to contain RFC2119 language, = and speaking as a co-author it seems reasonable here when we are setting ou= t the requirements for protocol development.

[[Sasha]] My point was not about usage or non-usage of RFC 2119 = language in Informational RFCs, but about consistency of their usage.<= /o:p>

It contai= ns:

-   = ;     Requirements that use the reserved IETF keywor= ds (e.g., “Any MNA solutions to these requirements MUST NOT rest= rict the generality of MPLS architecture”)

-   = ;     Requirements that use the non-capitalized words that, in their capitalized form, become the IETF keywords (e.g., ̶= 0;An MNA solution MUST respect the principle that Special Purpose &nbs= p;      Labels are the mechanism of last resort an= d therefore must m= inimize the number of new SPLs that are allocated“). Having a mix of = capitalized and non-capitalized terms in the same requirement looks problem= atic to me

-   = ;     Requirements that do not inc= lude any words that can be associated with the IETF reserved keywords (e.g.= , “NAIs are normally inserted at LERs, but MAY be processed at LSRs and LERs”).

 

MB> I agre= e that one is unclear. I think where we are not with the solutions, it woul= d 

make sense to= change 'normally' to MUST only be. SOme thing like "If NAIs are inser= ted in

a label stack= , they MUST only be inserted at the ingress LER for that label stack, and t= hey MAY be processed..."

[[Sasha]] Looks fine to me.

 

MB> I will= look through and clean up the other cases where there could be ambiguity.&= nbsp;[[Sasha]] OK

 =

I have se= nt my early comments to the draft authors, and they suggested that these sh= ould be submitted as the RTG-DIR review without any private discussions. I = am following this suggestion after adopting these comments to the RTG-DIR Early review template format.

MAJOR = ISSUES:

None foun= d.=

 =

MINOR = ISSUES:

1.      = ; The draft mentions RFC 3031 and RFC 3032 as the references for the MPLS architecture, but it d= oes not mention RFC 5331 that augments MPLS architecture with upstream-allocat= ed labels,  label context spaces and “context labels”. Doe= s this mean that MNA is expected to be incompatible with upstream-allocated labels and/or context label spaces? If yes, it wou= ld be nice to have this stated explicitly.

&nbs= p;

MB> Agreed. I will add a reference.

&nbs= p;

2.=    &n= bsp;   Item #7 in Section 3.1 as we= ll as items #2 and #3 in Section 3.4 seem to imply preference to Post-stack= ancillary data vs. In-stack one. Is this really the intention? If not, please consider stating explicitly that= these requirements do not preclude usage of In-stack ancillary data= .

 

MB> I am not sure it says that, and if in-stack was not allowed th= en we would have a requirement that says so. 

Maybe what we could add  "A solution MAY choose to use in-s= tack ancillary data, or it MAY 

choose to use post-stack ancillary data." as a first requirement= in 3.4?

[[Sasha]] Please note that the first problematic (from my POV) i= tem appears in Section 3.1., so adding another requirement in Section 3.4 m= ay be too late. Any text that eliminates any suggestion of bias towards In-stack or Post stack ancillary date would= do.

&nbs= p;

&nbs= p;

3.=    &n= bsp;   Section 3.9 of RFC 3031 stat= es that “the processing is always based on the top label, without reg= ard for the possibility that some number of other labels may have been "above it" in the past, or that some = number of other labels may be below it at present”.  (This princ= iple has been tweaked when “context labels” have been introduce= d in RFC 5331.)  IMHO and FWIW, it would be useful to explain what should happen to this architectural principle with regard to MNA.

 

MB> That may be better suited to the framework draft.

[[Sasha]] I assume this means the MNA Framework draft. If so then:

  • This document is not referenced in the draft under review, but t= he need to cross-check with the framework draft appears as an Editor’= s comment in Section 1.1.
  • After briefly looking up the framework document, it seems that t= his Editor’s comment highly relevant. I have to admit that I have com= pletely missed this aspect in my original review.
  • The framework document explicitly states in Section 2.4 that = 220;A network action sub-stack should never occur at the top of the MPLS label stack= 221;. This addresses (in a way) my original question but seems to be in con= tradiction with item#3 in Section 3.1 = of the requirements draft. Spreading these statements to two different documents looks problematic to me.

&nbs= p;

4.      = ; I suggest augmenting item #3= in Section 3.2 with a statement that reuse of an already allocated SPL for= MNA purposes would require its retirement and re-allocation in accordance with the process defined in RFC 7274. (This comment is based on the discussion of re-use of GAL for= MNA in the early days of the MPLS Open Design Team).

MB> I agree this is a useful clarification.

5.      = ; Do items#8 and #9 in Section= 3.3 consider SR-MPLS as one of the relevant control plane protocols? May I= suggest that an explicit list of such protocols be provided to avoid any possible misunderstandings?=

MB> No. SR-MPLS is not a control plane protocol, altho= ugh it may use a control plane protocol. The control plane protocols that c= an signal MPLS labels whether for segment routing or other cases that use an MPLS data plane include LDP, RSVP, BGP,= ISIS, OSPF... and there are numerous out of band mechanisms for programing= labels like SNMP, Netconf, etc. I do not think there is any need to define= what we mean by control plane protocols in this draft.

[[Sasha]] This is probably a misunderstanding, since my question= was about ISIS, OSPF and BGP extensions for SR-MPLS. It seems that you con= sider these protocols as relevant for the purpose of items #8 and #9 in Section 3.3 – and I am OK with= this.

6.      = ; Item #12 in Section 3.3 stat= es that “NAIs are normally inserted at LERs “:=

a.      = ; As mentioned above,. this st= atement does not carry any IETF keyword (MUST or SHOULD) to indicate the re= quirement level

b.      = ; I suspect that normality, li= ke beauty, is in the eye of the beholder. A more suitable wording could be = “LSRs SHOULD NOT insert NAI” (or something like that)

&nbs= p;

MB> See my response above.

7.      = ; Can you please clarify wheth= er the requirement in item#10 of Section 3.4 can be addressed by an LER tha= t is a head-end of an SR Policy (RFC 9256) that uses Binding SIDs in its list of segments? 

a.      = ; Usage of Binding SIDs makes = control over the depth of the label stack quite problematic for the head-en= d of an SR Policy

b.=    &n= bsp;   Another case when such contr= ol is problematic is usage of TI-LFA or Segment Routing Micro-loop Avoidance mechanisms.

MB> I agree with you that this is a problematic case. = Any inter-domain case (which is a common application of BSIDS) or case= s where the label stack is expanded using SR policies with BSIDS is an issue. As are tunnel-in-tunnel cases like LDP ov= er RSVP/SR-TE, BGP-LU over RSVP/SR-TE, etc. I think the requirement is stil= l valid, and we probably don't need to say anything more in a requirements&= nbsp;document. It is up to the solutions to solve the problem.

[[Sasha]] Item #6 in Section 3.1 says: “Any MNA solution specification MUST discuss the ECMP consequences of the design.”  I think th= at a similar statement about the need to discuss consequences of technologi= es that increase the depth of the label stack in a way that is not controlled by the ingress LER for this stack would be= very much in place.

NITS= :<= o:p>

1.      = ; The draft refers to draft-saad-mpls-miad-usecases for the description of new MPLS use cases= (both in the Introduction and Background sections). According to the Datat= racker this draft has been replaced by the MNA Usecases draft that is a MPLS WG document.  IMHO the reference= should updated accordingly.

MB>Agreed

2.      = ; I did not run the ID Checker= on the draft, so could have missed other nits.

MB> It passes.

&nbs= p;

Hopefully= , these notes will be useful.

Regards,<= /span>

Sasha<= /o:p>

 

 

Disclaimer

This e-mail together with any= attachments may contain information of Ribbon Communications Inc. and its = Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, relian= ce or distribution by others or forwarding without express permission is st= rictly prohibited. If you are not the intended recipient, please notify the= sender immediately and then delete all copies, including any attachments.

--_000_CO6PR03MB6290EAAFE0CAD31CA412F575F63AACO6PR03MB6290namp_--