Re: [Last-Call] Last Call: <draft-ietf-opsawg-l3sm-l3nm-10.txt> (A Layer 3 VPN Network YANG Model) to Proposed Standard
tom petch <daedulus@btconnect.com> Thu, 29 July 2021 11:13 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 B27B13A1E89; Thu, 29 Jul 2021 04:13:13 -0700 (PDT)
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 nxuYGXndlDSw; Thu, 29 Jul 2021 04:13:08 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20119.outbound.protection.outlook.com [40.107.2.119]) (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 8CE223A1E8F; Thu, 29 Jul 2021 04:13:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h7OFtTwAZ8emwv704f5SmkXkTNLFEiyXXzccab5pLRUPdIr8qQHhnuiU0kPj1BjMqjf2ZxJAIuJn1XMNe7EtQWY6T09OpZ/LzHWLmMris31yjBalud57xku5+00NciKq+9OpxfPPApztFIDldAFG6wb7DvcEF/KmR+SMGZixy4Waf03wxQnZ6Do2Tq4BpEwoXnCn3Vh91w3HqG0xNmZ3VivHiCBkp2T3ZRA+nQQCTGJDmNUoqp4WximnRqupCkMWAsZwUaOjnyLUw+q1GmqOI2UQDg1cZnwkqUdqqFlFgZS+69JqpKPqwaU3h1/easXrhDwOeeoa6BT/1PgOFFNuEA==
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=pRyR0nIlGDJGgxere/2RCvqAATY5tEMdda3Pimb2lVY=; b=QhSXg3E90p/H/ksZ3MwZBpoP8EJQN3kA2bfae4fEYi1PsjYtNGv05SK/FkbpXhG6SWYJGuaZgVN0ve4SM6EH2e0J6V0C9wRQDkm5pK9F1vdiwsiLruJ2Kw6wFw5KuZMBMxF4uz4yq32Kk0U6IRPS9I+ghvRTB+Qz1wE6CAUN9KMudaBvdx5ymjQ492Es38YORddKOsgYTYL+97GbIUfGijRuH8w8G7UHPGZAY/AvoPDgVKzXcuLrna1GWP0jMIyuXqaqAR/wJwZWLfBsanoD9NpFnS8YgC6+dvYDl8Usm/bP/hsD7SZSEg6q4jXOVNrc4tYeduiG3bb9LKj1sC8EtQ==
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=pRyR0nIlGDJGgxere/2RCvqAATY5tEMdda3Pimb2lVY=; b=O2hURbEOjj8/08sQeBzJPu9MscuUKSnk/fBqPEPVTBIYj/UhLVHxUg1hWk/eaJmuYCaMoxa0gXk1ufvjeWlRRNSPaJDBOnPULqYgyC7MmdMybo0ghtzn2EeeZVOq8jdNmlE0vl93lHCWMEYNT3e5T6UGKyXYPe3S7uYNL4ycmi0=
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 VI1PR0701MB2542.eurprd07.prod.outlook.com (2603:10a6:800:64::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.12; Thu, 29 Jul 2021 11:13:04 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::10f5:d159:cfea:1b95]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::10f5:d159:cfea:1b95%3]) with mapi id 15.20.4373.019; Thu, 29 Jul 2021 11:13:04 +0000
To: last-call@ietf.org
References: <162645153536.30354.1067320180395747972@ietfa.amsl.com>
Cc: adrian@olddog.co.uk, opsawg-chairs@ietf.org, draft-ietf-opsawg-l3sm-l3nm@ietf.org
From: tom petch <daedulus@btconnect.com>
Message-ID: <61028D33.5070904@btconnect.com>
Date: Thu, 29 Jul 2021 12:12:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <162645153536.30354.1067320180395747972@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0375.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::20) 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.231) by LO4P123CA0375.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4373.18 via Frontend Transport; Thu, 29 Jul 2021 11:13:03 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 6fedca5b-42fe-44c9-652d-08d95281d5d2
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2542:
X-Microsoft-Antispam-PRVS: <VI1PR0701MB25427BDAAAB746CBA1EB37EFC6EB9@VI1PR0701MB2542.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: HUGo0eHBJJg/qNDKU3etoBs9ZDacUZ9EsU+vraTQz5ECxzHJDE0LhgXZ+Cbr4SrpZWRd9NP8mJHix3BhJtrTKkWKMY/9BlTwwK3/d3MNzPxYNsAZsnehPbjQt0+RKcUD4ypEsFCZ3sYSj/3lTuH15dF1w7C0wAMxy8+lPK4IOHbVMLZ6wo4UmdpdO5WPiP61DuX18dT2ttyY/OLDUNO2gM/7mdMDipUJf3XgZClqKfneuLYZ4qblBX7es5bHUeiIgzBWTvi6yv32T3QGqoEoL0f/0zANFfEc8fiD/x23bNh7iHersDKMTZoB3gfFofJRu4E/tts/Z6o936kTOqtnStyxNsKJrzoZ+SW5JJ0Hcow8OzZkaupKJZyhOoPev0IieS3vB104yhulMx/M+ALDblA4zYoTbq9jA3fN25nzA1CjI1q/z6VGmnZSnaod5i7ldmgPj5SNLhCGLw1fRQOesk0G53Zs4fU7JPnJ7l8QKqJCh1hqrIHKK+N8e06X9Ax/FlLsCUI2y099iy1YwcwOTL0Ihck9rCcM2cmc4glGr3/Ff71bJI6fJSA5t9ioAM2JTHL3vz+H/Dlx+uKONedfb2821/Cvd5wx/VZx1fjmnN+bkn6sUa+d8AgWsb7LGJPAvMHVbrmd/h+ccDHeAmHFczvTUsB2WyPWPVDMrkb3MZP1Gxp8ackzhx1ww/PR4tVLQvXVX944pKUBOkSttorSzA==
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:(366004)(8936002)(87266011)(186003)(33656002)(508600001)(52116002)(66574015)(53546011)(6916009)(83380400001)(38100700002)(316002)(8676002)(956004)(6486002)(86362001)(36756003)(2906002)(26005)(4326008)(66556008)(38350700002)(66476007)(6666004)(2616005)(5660300002)(66946007)(16576012); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: cHdbRx0bXTvwJO8duAo7UhGaZZu4oVeJwueAyc2BYUAO60fhhcnweS2bkV6KuUe34qBOE4hjMMeaky5s3gKJ1gJTTQR7Ftn8aclRstSHNzEmkydKckGxjFWxwi2PYhR9EmfpF+P0pG/1Yp1ntO/JnLDH/KbDFTVbxUFLQNL9X+lavT8npwMb9ctnRd2jZd3yh/LdNy2eOiJ5DAEM1USzSy2ggtuoU2+XQbo1N9d5rVbY1p+2Qq5e2S9TlUV0EVqh27DNxiM4VibFV20b+ygYILwjWHvJS2LR4RPnwwDi+ZGxskzEoNfiUTak/Hn0upItVjnrLwQS0R7V5TD1aEyLlevydQPajk3VqRc1sQEmZ+VgqRXllDvxrDZlafvcF2uSDwkkWmBP/rpJ9ICQ728fevnQSKmbmtgTO4evWe2XNy5doMLHRhfFTTTlgWOo5097eCwPlK41QS1OiVkqqA+6jdZdaudpgz6OD95ikK7j1900GQxusvdFTYCn80Spu4fP90Ak20Hhm2qEwZqFRFzVG5E/WMdUFsPYvVytl07OFdUrQ/xqOk/CRS/xWC6Sg8OWX0Dgk8W0jZSCl8sWyoMfyxYntUDPIRGJVJmjji56DBWz0WlF8QQ/o48yYxmmH5RNEBXxTqZqBNPmCd1cKG0KbH0n0WWMTeojhvwgEQCCGUBOGDKEvkSm1xuUEEhGNu+yCehC/dGyiA4FcJ3mHF6KrCBV98fQrCDk8GwxHY2Nd5Zov9TT9No6JBDyXfXtgKm/je5PSrwagnZaNFZJoy/dzagGPRMKzCuzJfMEqctVZcl4gRb9MJ/cTidBRlFIVZtidonkKLLQovAeit9i+ksNkiNLtDNAZHZsOLHgYrqbKCQEp2YxUWyY6NQVR/Pyzo0qtT3W/j9H7WrtpK8fzyGOkZF62ghpW52FCoqmlS3kFzB/zC4tbOVHCDbiaNC2eUh+EdM5i2h4AI4DTuzyZpJsCfkaqUQrS+kHfyoSfH/Amz50sLEIpxqxGs7nosDJu5PYBqVuRtPZ4u9wBMoxipOvMgwbLKu06RiaoA6QduinVNK+KOndHfiyZkSlHEnVYx34JlLGzPuiLKKn3hZi/qiCTnuhpy0cawFkShYbWzp7q+o7uB3BnPr4byvElW2QbY4irpWJgvnslxpPBrjzr61jjek7k4EU6A51QA4E9ImZ0IAEFrmXFJxGw77WGKA2HvPbMKTNUnHcRleE6Lz51CRJcO4x8zrdOL4aUyZYJO87GuCtzIxMsc0ocSMIyqZevkRcIBC33tlpcr191P8xJ+vfHeo3zuYcVAEUieTD19lOwxHrPRfXUWJHBYbK4OCBXi3i
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fedca5b-42fe-44c9-652d-08d95281d5d2
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2021 11:13:04.3340 (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: v4yCN18GbjITXAOwnkFNqoA+ot0zPpX6wk3L9z1ut8RAZAgyneMYhBjTNBDaNL4K9ITH5ltNpDd+RpEX+Iuitw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2542
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/0hhDurpBHuK4xAcwrb3A94aB2J4>
Subject: Re: [Last-Call] Last Call: <draft-ietf-opsawg-l3sm-l3nm-10.txt> (A Layer 3 VPN Network YANG Model) 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, 29 Jul 2021 11:13:14 -0000
On 16/07/2021 17:05, The IESG wrote: > > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: - 'A Layer 3 > VPN Network YANG Model' > <draft-ietf-opsawg-l3sm-l3nm-10.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-08-06. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. This I-D includes a YANG module which provides configuration for BGP, OSPF, IS-IS, PIM, IGMP, VRRP, RIP, BFD, MLD, NTP, DHCP and such like and, as such, overlaps substantially with existing RFC and I-D. It does not build on that work, rather it takes a different direction, which seems likely to induce misunderstandings. At WG LC, the shepherd suggested that with so much coverage of VPN, then IETF LC should be flagged to the BESS WG so that they could review it; I see no sign of that having happened. By the same token, I think that that suggestion could apply to several other WG. Thus the coverage of BGP here seems at variance with much if not most of bgp-model. There is often a need in YANG to differentiate between this version, that version or both, which is modelled as a base YANG identity from which more specific ones are derived, using YANG's function 'derived-from-or-self' when a combination is wanted. Not here. Here there are three identity for e.g. ipv4; one for ipv4 alone, one for ipv6 alone and 'dualstack' for when both versions are present. Thus 'ipv6' has a different meaning to any other YANG module I know, meaning 'ipv6-without-ipv4', and a test for ipv6 becomes when "../address-family = 'vpn-common:ipv6' or " + "'vpn-common:dual-stack'" { while a test for ipv4 is when "../protocol-type = 'host' and " + "../address-family = 'vpn-common:ipv4' or " + "'vpn-common:dual-stack'"; The concept of dualstack will be familiar to those implementing hosts with IPv6 support but is not something I have ever seen elsewhere and may be unfamiliar to most, at least with this meaning as opposed to support of other related protocols perhaps outside ther remit of the IETF. Likewise, this use of address family, with different semantics, is inconsistent with its use in such as BGP and RFC8349 (inter alia). Unwise IMHO. I see this use of dualstack and address family as major flaws, show stoppers. For OSPF, other documents derive ospfv2 and ospfv3 from a base ospf identity and use that to specify ospfv2 or ospfv3, the natural way to model the OSPF protocols; here, OSPF is differentiated by 'address-family' i.e. by ipv4 or ipv6 or dualstack, not something I have ever seen with OSPF. What does it mean to activate IPv4, as specified here? OSPFv2 or OPSFv3 or both? If OSPFv3 is used to convey a IPv4 prefix, is that ospf/ipv4 or ospf/ipv6 or ospf/dualstack? The security options, in 'container keying-material' are at variance with those in draft-ietf-ospf-yang in 'container authentication', similar but different. Therein, 'case ipsec' is OPSFv3 only but there is no way to specify that here with its concept of an OSPF address family. The I-D defines a type for 'area-address' but this is not the one used by OSPF protocols. RIP, likewise, is diffentiated by address-family rather than by version. 'leaf flush-interval' here defaults to 180, which is invalid as it is not greater than the 'invalid-interval'; it is 240 in RFC8695. With BGP it seems more accurate to say that most objects here differ from their potential equivalents in bgp-yang, either in identifier, in description or in semantics. BGP, RFC4271, defines holdtime and keepalive - not here, where it is hold-time (with different semantics to RFC4271) and keepalive while 'address-family' has a narrower meaning than would be expected for BGP. There appears to be no way to configure the BGP identifier (for me, the first step). The local address does not allow configuration of the port. 'neighbor' configuration does not allow for identifier or port. Here 'multihop' is configured as leaf multihop { type uint8; description "Describes the number of IP hops allowed between a given BGP neighbor and the PE."; where draft-idr-bgp model has leaf multihop-ttl { type uint8; description "Time-to-live value to use when packets are sent to the referenced group or neighbors and ebgp-multihop is enabled"; which I find clearer. The limit on prefixes here is specified in container bgp-max-prefix as "It allows to control how many prefixes can be received from a neighbor." while draft-idr-bgp-model has "Maximum number of prefixes that will be accepted from the neighbour" which I find more precise. The point where the limit is applied matters; currently, there is a discussion in the IDR WG about specifying two different limits, one for inbound and one for outbound, a change which seems likely to be needed. More significantly, here restart-interval is leaf restart-interval { type uint16; units "minutes"; while bgp-model has leaf restart-timer { type uint32; units "seconds"; a difference in scale. Here the action is leaf warning-threshold type decimal64 { fraction-digits 5; range "0..100"; } units "percent"; whereas the bgp model has leaf shutdown-threshold-pct { type rt-types:percentage; a difference in approach leaf prepend-global-as controls the prepend of a second AS, the one for the node in addition to the one for VPN network access level. bgp-model has container set-as-path-prepend { description "Action to prepend local AS number to the AS-path a specified number of times"; which is, well, different. Here the specification of the holdtime only caters for its value once the session is established; as RFC4271 says, it may be set to a larger value during session establishment Compared to bgp-model there is an additional security option, case explicit { which I do not understand but would appear to have a key of type string which sounds like an unmentioned security vulnerability. Away from BGP, 'router-id' is imported from 'module ietf-routing-types' with the appropriate semantics and there is a definition of router-id as a 32 bit number in s.7.5 but then a second router-id leaf is created with the wrong semantics. The need for a second concept, an addressible one (which 'router-id' is not), has arisen before and draft-ietf-ospf-yang defines such an object and gave it a different name, 'te-rid', TE being one, but not the only, use thereof. Different semantics call for a different name; that name seems suitable for all uses if that is what is wanted here. (The I S I S yang module uses te-rid as well as ipv4-router-id, ipv6-router-id). When a range is specified, in YANG, which may be a single address, that case is commonly modeled by specifying 'start' = 'end'. Here it is modelled with only the start-address with the presence of the end-address implying a range but with no YANG constraint on the value of end-address vis-a-vis start address; that seems unnecessarily flexible. MD5 is part of the security options but is not mentioned in the Security Considerations; for the NTP yang data model, it was flagged as deprecated while the TLS WG is seeking to eliminate its use. Other minor comments typedef area-address { ... description "This type defines the area address format."; Well, worth adding this is not for OSPF Where 'start' and 'end' are specified, it is customary to impose a YANG constraint of 'start>end' or 'start>=end' leaf dr-priority { ... Numerically larger DR priority allows a node to be elected as a DR."; Well, any value allows election; perhaps, as draft-ietf-pim-yang, puts it "A larger value has a higher priority over a smaller value."; leaf update-interval { ... "Indicates the RIP update time. That is, the amount of time for which routing updates are sent."; Perhaps "Interval at which RIPv2 or RIPng updates are sent."; as per rtgwg-yang-rip leaf signalling-type { enum ldp { ... In this case, an IGP routing protocol must also be activated."; Probably 'MUST' and likewise for 'enum bgp' container service { leaf mtu { ... If CsC is enabled, the requested MTU will refer to the MPLS MTU and not to the IP MTU."; MPLS does not really do MTU; mpls-base-yang uses 'leaf maximum-labeled-packet' after a discussion about this issue. CsC should appear in terminology. Tom Petch
- Re: [Last-Call] Last Call: <draft-ietf-opsawg-l3s… tom petch
- Re: [Last-Call] Last Call: <draft-ietf-opsawg-l3s… mohamed.boucadair