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> Mon, 30 November 2020 10:47 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 097613A03FC; Mon, 30 Nov 2020 02:47:20 -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 7nVnKH5KMoYf; Mon, 30 Nov 2020 02:47:18 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10137.outbound.protection.outlook.com [40.107.1.137]) (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 D45B83A033F; Mon, 30 Nov 2020 02:47:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WHwaZaS+z/yIxMxr3g58FE9X9mFT0mc9BzrxQ6ItmJKqKRGIuYZrO+ACf1qs4H4q34mCOq6IUiM5SnSozkZ4X+1EQvwYr83Eh3LXCIXqTbZT5/D8/7rIKoI6UkdaI3o1lhh+zNq4SsLDfKIJhb/L8SGYeFVefRATpSucFC34ML2P+J/JiedJl9l6RZAqgG8f5hQd4kKah/+QQDgXWNGwzeGN/2pNxJuKJAEr/eM+7tSrGQVogR04Es/SW3kXM7LUnEE3YcV63wvexlc1wOQ9l08fdm8Iu/pFO5kujS5pK+RpOxhTtcrhMt38pmAqg0RYbWWSuB2ndiR9ZhHpZblm+w==
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=HUQFHx/Tyq2Fi6GWCqmNAVw4cb18+li8Ve7/6R3ApUE=; b=DlYL+AMOccIH3FQ6NGVw3UsPeeigq1LTL2PInr20dYDOyPzTVFnu62+EKrrFtO8n1vF22+NW6O4V1D3CQQe1x5dFEphV59kxcUpexpnrE9t1CDUZxtXc//I2j8ICR1cFIaapiCKueEwz2jb53++LJtFrt797O0edKYHyyeQQKlB01yPy6F/m8MPfcfEXZJlvlFa4l0vHeIHI9A0mXI88yV0YPiz/iMeQmI6s1U9mqG+1qK/2yY0JS/yLP+N1mLT4uJvNigK+J/pMyvNprdZZUoSsDG6AJ26oT0oe8u769qPx0jXdPX/whJoBgj3UVH4ajgT8G5l7N1pwbhwFhPxsmA==
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=HUQFHx/Tyq2Fi6GWCqmNAVw4cb18+li8Ve7/6R3ApUE=; b=oi1lhYMF0AGpvylaNFHaeNi3OFcjPTk2yhZHsEZkba5uYQu+QGBpVAVahnCbdSkrDw3RW2nWhpGk9GHSjjiADer9hxucbteZa9A+ndKhSPONZcZiLdl8froA4CgCmJmXPpuen7yCj3VQbimHQKm/G+OByTdxynRXaIVGihsDH0c=
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 VI1PR07MB6669.eurprd07.prod.outlook.com (2603:10a6:800:185::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Mon, 30 Nov 2020 10:47:10 +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.3632.016; Mon, 30 Nov 2020 10:47:10 +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> <5FBF86B2.7020907@btconnect.com> <2E1DE08B-47AA-4D29-8ACD-30335BDFFCFE@cisco.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: <5FC4CDA8.2030803@btconnect.com>
Date: Mon, 30 Nov 2020 10:47:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <2E1DE08B-47AA-4D29-8ACD-30335BDFFCFE@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [86.146.121.140]
X-ClientProxiedBy: LNXP265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::31) 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 LNXP265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3611.20 via Frontend Transport; Mon, 30 Nov 2020 10:47:09 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: dab2bb70-6cda-4c0b-67d6-08d8951d4a09
X-MS-TrafficTypeDiagnostic: VI1PR07MB6669:
X-Microsoft-Antispam-PRVS: <VI1PR07MB66696F47EF4CF126DCC8553DC6F50@VI1PR07MB6669.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:1227;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: xeeEmky50uNeKp99ojyM2bpfAiOHeC+gZOhNBmxVJ2JBaSvSFneT4LxmC6e3bPGn7Rtacm10h/InbIExJ4rDjkzVDxkCc5iUikzeEAeg7NPkCK+3Gx/8y8SEnyM7xb8JfMhHJWpt9ucbE6zT2rSH4J9NjyEg5rXtCaSYFmP8sKRIu3eqzLsPVrso4KGXRAA6Kot32lISqoJrpeINe8GgBcpdSpu7oPDhjCLUu1DIVHkPaTUUB2TRUVt5BHzutApm1JfN9sWNmX2Q+bdI0R2T6h8ErQMMLM6CmOqNCmn8HpxZKmpyTBp8/g2xnZmniOyTfglS8xDG0E8GpVT/CiNzDA==
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:(39860400002)(136003)(376002)(346002)(396003)(366004)(52116002)(4326008)(86362001)(6666004)(26005)(66946007)(33656002)(66476007)(66556008)(8936002)(110136005)(5660300002)(8676002)(66574015)(16526019)(36756003)(83380400001)(53546011)(478600001)(6486002)(186003)(956004)(2616005)(316002)(16576012)(2906002)(54906003)(87266011); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?d0lhQmYvVnpENCtTMCtLaWFFNkVzMUNLK2Q1dGwraDFjTFdFZ25PQ1RTYk1o?= =?utf-8?B?R0QrdldpMW9qakZMbVpQbC9hc0duNjliRy9RbXZ3TnBWMUlZMG5ramV0RFVw?= =?utf-8?B?OU9mYW5JakhMWFdSd1pMdExzMU1wcXZxQjM3QzNGTFV5NHJKQzhUeEZ0cHhN?= =?utf-8?B?UjloZzVVZ3RzdWhUaUpiekFUQW9VL212U1FpTWx2cnFQTENiSjVGOG1LTE01?= =?utf-8?B?YnJzTnBSNU9qVzJxZWZFL2FyeSthdDg3L201dmpOQWFScUw4RHVMV3N1RTYw?= =?utf-8?B?bDcxR0t0Rkt0TkxFVTFUNFUxZFFQNm5pS2hqQysweDMwYmtDMzdJK3hFOTUx?= =?utf-8?B?bkF3aFRpeEs2R2tKdlpUNDVpZmYyZHpFMThDL3lKU1Y0Uzd6OXd2aytFVDI2?= =?utf-8?B?OGVyRVZiblpLRGx1MTR5VjBTZm1Mc2luUlk5NC9vYU1yUVB3dkJCQ0ZxYmdK?= =?utf-8?B?eG1xc3dDanhCSFdYeXlVendaeW82dlBha2hwRVhhYkM5WUlIcVVJbmovQU42?= =?utf-8?B?MHhjci9UVkxtbVNyVnlrNEpVSkxINE5TZWYwQ00xbHV0NEJpby94b3Uyc3Va?= =?utf-8?B?VXR1ZnZwaHI3anRHeEppSTlPOW1NbkVhT0FIMXN6UWZPc0J6WDlaVnE4dDRs?= =?utf-8?B?TDROZ2xLNDI1QWJ2d25wTmJEQWQyNjNOOE0wS1B2aEZ3clpjOEEvQkt4OG52?= =?utf-8?B?NXpSY0lqSTF5UVNiSXpSUHdoc29OUEVVajYyTmtGcXczblphOGhZL2hKYUNj?= =?utf-8?B?NmVsZVJYcXhKMC9QVUxXTjE5YlVsdW96VS96S2daeUp1dXZvSjQwNU5IUUZa?= =?utf-8?B?bDVJcXNSNy9MRXpVNG5aMDdQclZISWRTYWRIZE9SSGRJb1I1YmRIUTRjZERX?= =?utf-8?B?UDJPeTdaWFE5M1Q1RFI1SHNqZGs4MFJwVkVSNXRyVFQxd3B0L203N2VjdXNu?= =?utf-8?B?NElIVU5sSzZGL0E1Vk5ETHkwMDUvTE9ua1JnRk43bVZGZGJSaTNsSEhVRTJy?= =?utf-8?B?d0JjbDlDdE1sSnplQ0FmZ1FIT0ZWUnlrUXpWcjZBaWEzKzhQZmtuR3gyUENm?= =?utf-8?B?Y2U2bUxNNzVWeUV4NHhNQjN4M2V0RGN2aWQwTU5JRzdBSzJVMHBBYjFsNytp?= =?utf-8?B?RExla2dsTE5JTWRGU29FcXBlcFNoNmkwOVB6eno0WkxIaW96RDM1SC81VnNL?= =?utf-8?B?RlBaY1VwWUZlT3FVVjdoZ0lLNFpYK09SL3k1dno1Ykp2ekdGVHZ6bEpwK0Ro?= =?utf-8?B?SjRLZG10T25jVEpkT245UTBZeUpyVHAxaUZEd2tJNWxTeGZkVHovU2FZN1h3?= =?utf-8?Q?4LSLQtXMlLDbZChyggfPR+kr1pOHzmDKBP?=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2020 10:47:10.0461 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-Network-Message-Id: dab2bb70-6cda-4c0b-67d6-08d8951d4a09
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AEylMdomS96TgXP0SyO/jqb0nIz6zinbBNpVoSb3H9sQbCdDXzdj0RrN9XjMroPw70wp5DCPPPA65fMQgAzplw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6669
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/ldHaYOYcYA0PFTCF_TsxIxSRAKg>
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: Mon, 30 Nov 2020 10:47:20 -0000

On 27/11/2020 14:35, Acee Lindem (acee) wrote:
> Hi Tom
> Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:".

Acee
I was too slow to see -27 but have looked at -28:-)  Yes I like the 
references to BGP.  I do sense a reluctance to reference I-D from other 
WG with the potential delays that can cause so that e.g. 'weight' could 
reference an IDR I-D alongside the LSR ones but I am not too fussed 
about that.  I do see a 'deptt' that might be 'depth' in a BGP reference 
to RFC 8814.
I think that s.3 needs updating.  I have done my homework and see the 
split in the YANG modules that came in with -15.  I think that s.3 
describes the old segment-routing when it had some data in it which it 
no longer has.  The description clause in segment-routing also probably 
overstates the case for what it now is, just an anchor waiting to be 
augmented.
I note that Table 1 omits the prefix defined in this I-D which I can 
live with.

Tom Petch


> Thanks,
> Acee
>
> On 11/26/20, 5:43 AM, "tom petch" <daedulus@btconnect.com> wrote:
>
>  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
>