Re: [Last-Call] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard

tom petch <daedulus@btconnect.com> Thu, 26 November 2020 10:43 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA83A110A; Thu, 26 Nov 2020 02:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 dgFYGuHvHGXk; Thu, 26 Nov 2020 02:43:05 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60109.outbound.protection.outlook.com [40.107.6.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBFC3A1109; Thu, 26 Nov 2020 02:43:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVkLQj+SZbUlcZUqOqdkgw5TZcgUDt6k3hK2lEbkrU5PozAMHNHgHIAIzS+YHTTU8ParSmqTEB98aqnZHHgANqoMkVVymj0xW+FR39QmU7/cXSY62RZ0HxmwFLFcF47yYRhpUXLu6HcUViMqgWP2VFffKSJpgA2yWzMyFa6rZLqO7Cy/1SlAUJRzlwtVcIq7STCljWmSc6Cy5FIPc8aiulNioq6VlFHWCrleLfzTEWQUbOpmjOtVPD4vvuLchuZcXhhv7JyyFcqaNwvoxMvSWpYzO7sSZF4qKWHmrVEea1pslRDPz80tCab1+uCYemrozzRauLGtwWLCfdRCzvvnnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jYJ6FzAmihE4jpf8cYRoX/JTbkgMyBzlmX/SN//WJDY=; b=BEzj+8XvjqsvBH60bi/LzxXJZlRt+iHWiitDKmlA0lc45bTc+ajpnIBfeamBLxifcJ3U0vVXFX1ABZvm9uKtK1QwiBH90QPFB0U82fStXUwbN1sFYWJjFbRsqkPdkqQQQm/SVgKQZQtPFPp/w1Q4Iy0Rbl0ZUSgP+kU9GBESSaBfj8/y2VmYKdu2YRxMLvnA6Dx3QXSb7kvBQFDaJFW3NvKZxK4Gf24ZjSlfhdQTMbE5tVoS16EMHtWUuDLFLdwu43n6tRaFrZmFZdfCpgpNVgBEnVBRm4pbaj5hrzt9pOGQc99seIvmiliEoKGTe1qmMJo1HN3B7qpnmPdo04LOUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jYJ6FzAmihE4jpf8cYRoX/JTbkgMyBzlmX/SN//WJDY=; b=tMfGAWA/oCydXJ9mDdNw+50gTk8X7qAxczgdngS25TeYLqt4b32NBwNlNcAFXXXVsKMqCjwoxBNLlD0xlHuioBNJx77y0QhEr6wPNK98OzzVN7sleIQhS1Hnw2XN6igaL5wro7er0WaLN6oiNbWiIZ/FQMja67gMIILzWHnheA4=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB5341.eurprd07.prod.outlook.com (2603:10a6:803:af::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.9; Thu, 26 Nov 2020 10:43:02 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3611.022; Thu, 26 Nov 2020 10:43:02 +0000
To: "Acee Lindem (acee)" <acee@cisco.com>, "last-call@ietf.org" <last-call@ietf.org>
References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <FE952290-CC70-4F30-8F22-6BC20D676FAB@cisco.com> <5FBCD392.3050706@btconnect.com>
Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "draft-ietf-spring-sr-yang@ietf.org" <draft-ietf-spring-sr-yang@ietf.org>
From: tom petch <daedulus@btconnect.com>
Message-ID: <5FBF86B2.7020907@btconnect.com>
Date: Thu, 26 Nov 2020 10:42:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <5FBCD392.3050706@btconnect.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [86.146.121.140]
X-ClientProxiedBy: LO2P265CA0208.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::28) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0208.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3611.20 via Frontend Transport; Thu, 26 Nov 2020 10:43:01 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b95ae52e-4f7d-40c8-4626-08d891f80c5b
X-MS-TrafficTypeDiagnostic: VI1PR07MB5341:
X-Microsoft-Antispam-PRVS: <VI1PR07MB53413ACAE0F685460522FAA1C6F90@VI1PR07MB5341.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:962;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: SYEOZ1AUA1gvrG0FzUYntmM4ap1lzzGE783fjk4ZyVRqUiPyMOYkCpYze4wGjv02l/mJcjuDi/gXXd7rw0glwLsrfkmcaIGcsHQLQAuFPZYzyWb0SFkIdHyxU57SqUPqIMu1c9hbSniXQtqo5l+xFgYw0dk5caUxSDKwuDEW99pRhpsI2c48xizrmXZBnIg0eV66QtJ2UzS0P8E0NTQUzbAAra3gnvvCouno4NJfhXxW9HTE7j/C7wV8Ni7YRV6EgYnB5EfgYPiEiLcBJrPOPaqrKW1bVKAwz25kQaKwSXjNLoV1iGkNJ/06aHf21wJ9hPFe+Pan47rMb50WT0YYNw==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(376002)(346002)(39860400002)(16526019)(186003)(5660300002)(16576012)(86362001)(6666004)(66476007)(36756003)(66946007)(6486002)(87266011)(110136005)(316002)(4326008)(66574015)(2616005)(54906003)(26005)(52116002)(478600001)(956004)(8936002)(8676002)(66556008)(2906002)(53546011)(83380400001)(33656002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?YWVENEZRemszYitQRmhwSEo4TndqOHBHTjd4NmFlMDhiUlZoQXkyT1hHdGxy?= =?utf-8?B?eTc4L0ZWdmdicmZRNnhhR1lBTTJ0dDZxTCtnZnM2WGs2TE5sSlFUaE9KZHA2?= =?utf-8?B?SVFkdVpaZCs1TFpYcVNhdHM3ci9pUzQzRk1TejJqb1FaakxNbXRiWXZ4dGpY?= =?utf-8?B?YzRSeUNWZ2xsQitQV0E3Rk4wSlpic3ZlWFNlTzlaRHk2Z3JkK04yUEE0eWdq?= =?utf-8?B?ck11NjZPMUR0VWFxZ0tZeXRGT1RwNUxTTTc3b29OWDJSUm5iN1F3ajRkaW4x?= =?utf-8?B?d0h5Q1VHeCtOTGx5V0gwMUVvdnBhTEZjZi9KRXRzdVFlK2txYkRCQktGdkRw?= =?utf-8?B?MTZoQlB1WG94cm54c3hHNjJkSFAreE1DbUhXUlFxM01LTzlQQWZZL2MrMkx6?= =?utf-8?B?QzgzeXo4NExPZXlZSDRyeDY1bng5ZGx1anRKRTJhQ2o3ZVFJSHAvQjJJQ2to?= =?utf-8?B?NmR6VTNRZklOUnc5ZmcxZThSSFUxcHJ4RFYvYjVHWUNWd29OemVYRkY4dldY?= =?utf-8?B?ZGk1QUF1TnRnM0h5S1NOZ0w0Zjk1QnlYK3RkNGpwTzVnd3paV09vNUorZi9p?= =?utf-8?B?WWFmOXNQTXBrQUZnYTdqbit2NEJCK0hnVzZ1aVRYZTFnNjd0VTJPOEpSL0tE?= =?utf-8?B?YnhDK1VjeXl0N3B4NmlZNUM5MnVaVDEzYjBuSW80djE1OWNubUhrUHJaY1RE?= =?utf-8?B?aHJvUk84aUhIQnFkTENxYWdvZTMra3pPS243VlZ3M1YrM2NLT3FsN0FXbDFK?= =?utf-8?B?WjBYL09nUllBaThoT1QxS1lBRk5CcVZsWXE1b3Y5M29GdGV4SE9yd2Zvd3Fi?= =?utf-8?B?MnJDZ1I4WEdITGp0SHRxZDU2RGtvRDM3VVRRVmUxN01lQ1JaVjdaSWVwdnBE?= =?utf-8?B?VWI0TVRxdWJMTE9NMHNyUHhlS2ZLbG1Dc3lqQzZiT0VmZ0paWG1teXhjdnRE?= =?utf-8?B?MmJURk84UFRtU2Zvb0IxNUZ0d0JuQ0dKMmlkUjVrYStBS3VRMEoyeFQxdW9W?= =?utf-8?B?YmZNT3V2TEU4YyszRlpyZmtRem4xbXREZDZJaG5ldG1MQXJEQWlPeWpyR0h6?= =?utf-8?B?a29SREd4L0hqVmVRb1lSNzE1Ujg4UStHcTdWQStvVUVGNzJqdnZoek0za1pM?= =?utf-8?B?SzViRXp6YVcwa1BnNUFnM0cvdTBMcHA5U3dsWWxzV09tdmRvNUs5bElwd2tk?= =?utf-8?B?cndralVTWFRFaTM3ZTErTmVxYksxSnE5Qzg0dnFaSE5rRFNTSUtWOHJkdHR3?= =?utf-8?B?NlN4RXZFNXYwQTdWRVJQbUtUZDZERHZQdDFFakVTVERpR29BdmloZm9Ob2Vv?= =?utf-8?Q?Pv0qY46dRMvOeAQkfFzN1Zdjt/wwPtZbO3?=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b95ae52e-4f7d-40c8-4626-08d891f80c5b
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2020 10:43:02.0908 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7xpIKMOWCuIU9xq5X786TBAY4fXiUQ0x9NoXEebbnskt8z9Goyzvh3DFhYgi5CsPfiQEnLpw4qeUxbuW4t5Axw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5341
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/yDZQoNeJAhSChylXnBwCakBVuAU>
Subject: Re: [Last-Call] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2020 10:43:08 -0000

I have looked at -26 and it looks good apart from BGP.

BGP gets a mention in passing but does not get the same treatment as the 
protocols of the LSR WG.  I am unclear whether or not this I-D is 
intended to include networks using BGP or not with e.g. signalling of 
MSD and would value a clarification in the I-D.

I wonder about the final D in
Maximum SID Depth (MSD)D
in the YANG; I suspect that it is spurious.

Tom Petch

On 24/11/2020 09:34, tom petch wrote:
> On 23/11/2020 17:27, Acee Lindem (acee) wrote:
>> Hi Tom,
>>
>> See a couple responses inline enclosed in <acee> and </acee>. We are
>> addressing the rest of your comments.
>>
>> On 11/18/20, 7:39 AM, "tom petch" <daedulus@btconnect.com> wrote:
>>
>>      IANA Considerations does not register the module names used in
>> the modules
>>
>> <acee>
>> This is in the IANA considerations...
>
> <tp>
> Indeed; I do not see a registration of ietf-segment-routing-mpls!
>
>>     This document registers a YANG module in the YANG Module Names
>>     registry [RFC6020].
>>
>>        name: ietf-segment-routing-common
>>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
>>        prefix: sr-cmn
>>        reference: RFC XXXX
>>
>>        name: ietf-segment-routing
>>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
>>        prefix: sr
>>        reference: RFC XXXX
>>
>>        name: ietf-segment-routing
>>        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
>>        prefix: sr-mpls
>>        reference: RFC XXXX
>> </acee>
>>
>>      Examples are IPv4 only, IPv6 would be good
>>
>>      BGP is included when it comes to defining a router-id but is ignored
>>      everywhere else, such as signalling MSD, protocol extensions etc
>>
>>      reference "RFC XXXX" would be improved by including the title in all
>>      cases not just some
>>
>>      the scheme http: appears in many places.  It would be lovely if this
>>      really was the scheme but I fear that it is not
>> <acee>
>> This is directly from the RFC 8407 template in Appendix B. What would
>> you suggest?
>
> <tp>
> Many I-D do now specify https: since that is now the only option
> supported by the IETF; I have seen this called for by an AD.
>
>
>> </acee>
>>
>>      module srcmn
>>        the upper bound must be larger
>>        the value must be greater
>>      consistency is good - I think greater is better
>>
>>      8.3
>>      operation states
>>      usually operational
>>
>>      two imports lack references
>>
>>      typedef router-id
>>      this is a well known type from RFC8394; it seems likely to
>> confuse to
>>      redefine it with a related but different meaning
>>
>>      leaf enabled
>>      enables protocol extensions
>>      which protocols?
>>
>>      leaf protected
>>      it is used to protect
>>      how does it do that:-)
>>
>>      enum dual
>>      ... In this case will be advertised with backup flag set
>>      What is the backup flag?  It does not feature in RFC8660.  Needs an
>>      explanation and reference
>>
>>      container link-msd
>>        list link-msds
>>          leaf msd
>>      The usual YANG convention is for a list to be plural and the leaf
>>      singular.  You have the plural list but not the leaf.
>> <acee>
>> So you are asking for a change from "leaf msd" to "leaf link-msd"?
>
> <tp>
> Yes I would especially given node-msd.  I wish that YANG Guidelines said
> more about container names.  I think that having the same identifier for
> container, for list, for leaf (which I have seen in another I-D)
> will lead to mistakes so having a convention for list and leaf will
> reduce mistakes but having another for container would be even better.
> That said, I have yet to think of a good convention
> In passing, must link-msd be >= node-msd?
>
>> </acee>
>>
>>
>>   And who needs the
>>      container?  This is mpls not a common module that might be
>> augmented so
>>      what does the container give apart from complexity?
>>
>>      list policy
>>        leaf string
>>      YANG string caters for very large items of very complex character
>> sets.
>>        Is that desirable?
>> <acee>
>> IETF models normally do not limit identifiers. An individual
>> implementation could do this with a deviation.
>
> <tp>
> I know - I did see an AD challenge that, I think in IESG review, not
> long ago.  SMI was better at this!
>
> Tom Petch
>
>> </acee>
>>
>> Thanks,
>> Acee
>>
>>      leaf used
>>      will used plus free equal size?
>>
>>      Indicates if the binding is /instal/installed/
>>
>>      notification-segment-routing-global-srgb-collision
>>      a mix of conflict and collision;  consistency is good and I
>> prefer the
>>      latter which is the name of the notification
>>
>>      containing /s/a/ mapping
>>
>>      ... sid collision
>>      again consistency good, prefer collision to conflicting
>>
>>      s.9
>>      I would have thought the srgb worthy of mention under sensitive
>> nodes
>>
>>      Tom Petch
>>
>>
>>      On 16/11/2020 19:32, The IESG wrote:
>>      >
>>      > The IESG has received a request from the Source Packet Routing
>> in Networking