Re: [mpls] Structure of draft-ietf-mpls-static-yang
tom petch <ietfc@btconnect.com> Wed, 21 November 2018 12:13 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D79130D7A; Wed, 21 Nov 2018 04:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 7gr6GSWqis5L; Wed, 21 Nov 2018 04:13:46 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::70c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CA5130F3F; Wed, 21 Nov 2018 04:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E55lVZHMhP5I82/H+lPCs4cgmC4Ey+7s7mLBu/rcZbw=; b=VyS548hTyYFtvPYHDqUHpoJjKc/zu/tKfMZGUaJqz+SzIqHxVErHklmah6Objm9K2TpuQofRcHL5+7yAsYvljm+H6+JpCLFwhSf7H8Gc0zDmo/M3ham47n8XU7CaWqnivYWze07LO6tC3vkfMzzsKfXW7yWgpKO7R2UkRq/hd4o=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB5661.eurprd07.prod.outlook.com (20.178.120.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.7; Wed, 21 Nov 2018 12:13:41 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887%4]) with mapi id 15.20.1361.015; Wed, 21 Nov 2018 12:13:41 +0000
From: tom petch <ietfc@btconnect.com>
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>, mpls <mpls@ietf.org>
CC: "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Thread-Topic: Structure of draft-ietf-mpls-static-yang
Thread-Index: AQHUgZOku1mW2++U0EauVlTgZISUEQ==
Date: Wed, 21 Nov 2018 12:13:41 +0000
Message-ID: <03e901d48193$5f293a20$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: CWXP265CA0046.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2d::34) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.128.101.213]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5661; 6:ZPvjKq2g44NiYeaxuYt1ytNJw1RfkicPxasTmnIfEWAQQkFkKK75A1DZwVFRZMvyxauaAU4Gtqn6vNwdW/T+HfZ+Vjcbln5tYabQnCSiGgRTNpYLhk0yYxZr0JFI+hZlbWkM7jWc8mgNotlzT6UXu2HXM3RPcxSd+szDNtmhmxsrVGlfcMwTmyni9PgkKWMi+IG1reYwobChOUxmE0txvZUwTEVK9bq7BoB1Hd6OGq3IibKylDHntAtV+WtbBeMNfZXM9vSRfyYio11eD9r6WdWD8QYmVRg+tehaulq9gkN7PMhu7iebG7b8i2pX4PVxFPwcPPb8kfzYKuEwTzQQBAmBgJarD3QzAJN3iTNFfG1tL5zpMSBa2hw+uc3t3E6KEhw6jA5m+OqsjlQ9l7Q2OPNeX9R07GPHWVDrng9fW97UfxfSVH+yEL/t18tkh/UMAlzE5y2VRkL9glxgbfC87A==; 5:l4VCXYDiflCtYO3aG4W5XlEvp7YOPjw1HOy0UON7tqwZQbRZhn74HHUv2uvh2zw+xY/4wOhYDPfbKGoKHpZxeKbygs2cppfqZwskMLEPJUSC087sk/14/jz+T+y+HWF7U0lzotHp6DOnbIG0JvLLBD2WUOQWn842S6Fy0SlC1rw=; 7:NmnVa4wOQjD9EexIUzY8K6uKrUr24siOKNKMw4+JHI56cueWyW6dt1eCxmSwSdHJbi2yPkMkTNyb0Dj+Avz4aXT2ye327R8Xa4kSqB0QtvC2C/xJUbNP5d1aiM/sZSVTTPv/wlJynv3aKxoOk10qKg==
x-ms-office365-filtering-correlation-id: d9d08c00-1085-4392-f213-08d64faac690
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB5661;
x-ms-traffictypediagnostic: VI1PR07MB5661:
x-microsoft-antispam-prvs: <VI1PR07MB5661A915EF1461D7BF24ADABA0DA0@VI1PR07MB5661.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231442)(944501410)(52105112)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5661; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5661;
x-forefront-prvs: 08635C03D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(136003)(396003)(13464003)(37854004)(54094003)(51444003)(51914003)(189003)(199004)(6512007)(25786009)(186003)(110136005)(105586002)(6436002)(106356001)(33896004)(53936002)(84392002)(68736007)(14454004)(2906002)(3846002)(478600001)(6116002)(71200400001)(102836004)(71190400001)(1556002)(4326008)(2900100001)(486006)(476003)(26005)(6246003)(316002)(256004)(86362001)(53546011)(6506007)(386003)(97736004)(52116002)(5660300001)(66066001)(7736002)(305945005)(229853002)(86152003)(99286004)(8676002)(44736005)(9686003)(14496001)(8936002)(6486002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5661; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Qzr6TqwRvFsEcGnLMq9NdycCJCJtvo4kfjXZVuu/uzTX5WGx5I9wxVPZzMBYzCcm2BRJgUJsr6Yof8aXIP5RfxOnGzHpJZaRwMDB36Um2eAiZQDB/0xrqr3j5clCps4XXFoMUmO1kiiU8jP3cLGjpcZ/jo/moxO/zYyJdoa11rKxTgfMXc58mVErNVQ0ws7x4ECGeSZvW5tXCIWgNrtfiSkr57QCUZB2zlbYWasvzli9c6aX7Rfcv9ngzgXyk+8feTblLmbBIXoY+zB0MsY6ZrquvS+GgwGcGA7bKmdGUFCXOKyLNRF5bzR0rAVKzGsAmVk63wD2kNBSwHznDYLMWlr/DLKfBuoiKQD1tUNwwHU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5D1356D5D9BC4A43A661C352823C67A9@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9d08c00-1085-4392-f213-08d64faac690
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2018 12:13:41.6628 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5661
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/zp8u7f-tRAt4IM-SGPynEPue7Oo>
Subject: Re: [mpls] Structure of draft-ietf-mpls-static-yang
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 12:13:50 -0000
Tarek, On address family, I think that this is a lost cause, there are too many of them! You use the definition in RFC8349 which ties the use of address family to RIB which seems to mean there will be a mpls RIB distinct from the ipv4-unicast or ipv6-unicast RIB. But then the module contains when "derived-from-or-self(../../../../../rt:address-family, " + "'mpls:mpls')" { description "This augment is valid only for IPv4 unicast."; which confuses me - to restrict this to IPv4 unicast, I would expect + "'v4ur:ipv4-unicast')" { but then that does not make it mpls specific - it will augment all ipv4-unicast routes. (Should there be a ipv4-unicast-mpls address family/RIB? I don't think so). While I have some familiarity with the technology of MPLS (and its management by SMI), I still struggle to fit MPLS into the framework of RFC8349, even though MPLS gets a specific mention in that RFC, namely " o The data model should be suitable for the common address families -- in particular, IPv4 and IPv6 -- and for unicast and multicast routing, as well as Multiprotocol Label Switching (MPLS). " Whether that text intends to say that MPLS is an address family, I find ambiguous. Meanwhile, I have gone fishing on the netmod WG list. Tom Petch ----- Original Message ----- From: "t.petch" <ietfc@btconnect.com> To: "Tarek Saad (tsaad)" <tsaad@cisco.com>; "mpls" <mpls@ietf.org>; <teas@ietf.org>; <draft-ietf-ospf-yang@ietf.org> Cc: <draft-ietf-mpls-base-yang@ietf.org> Sent: Thursday, November 15, 2018 1:00 PM Subject: Re: Structure of draft-ietf-mpls-static-yang > Tarek > > Thanks for the explanation. I did some more digging on Address Families > and have posted my thoughts to rtgwg; any one WG looks fine, look across > the Routing Area and I think the work would benefit from more > coordination. > > On the more specific topic of this I-D, there are already several > definitions of mpls address families e.g. > identity mpls-address-family { > base "address-family"; description "MPLS RIB address family."; } > in > draft-ietf-i2rs-rib-data-model > > and that may be a challenge to resolve. > > Tom Petch > > ----- Original Message ----- > From: "Tarek Saad (tsaad)" <tsaad@cisco.com> > To: "tom petch" <ietfc@btconnect.com>; "mpls" <mpls@ietf.org>; > <teas@ietf.org>; <draft-ietf-ospf-yang@ietf.org> > Cc: <draft-ietf-mpls-base-yang@ietf.org> > Sent: Wednesday, November 14, 2018 2:24 PM > Subject: Re: Structure of draft-ietf-mpls-static-yang > > > > + draft-ietf-ospf-yang authors > > + teas alias to comment on the utility of TE router-ID in the OSPF > YANG model for other non-MPLS technologies too. > > > > Hi Tom, > > > > Inline.. > > > > -----Original Message----- > > From: tom petch <ietfc@btconnect.com> > > Date: Tuesday, November 13, 2018 at 12:19 PM > > To: Tarek Saad <tsaad@cisco.com>, mpls <mpls@ietf.org> > > Cc: "draft-ietf-mpls-base-yang@ietf.org" > <draft-ietf-mpls-base-yang@ietf.org> > > Subject: Re: Structure of draft-ietf-mpls-static-yang > > > > ----- Original Message ----- > > From: "Tarek Saad (tsaad)" <tsaad@cisco.com> > > Sent: Tuesday, November 13, 2018 4:31 PM > > > > > Hi Tom, > > > > > > Thanks. To me, RIP/OSPF/PIM/BGP are all control plane protocols > and > > would think should exist below /routing/control-plane-protocols. > > > MPLS on the contrary is a forwarding augmentation to existing > V4/V6 > > routing table(s) (which are already defined at path > > /routing/ribs/rib/routes/route/next-hop ) - the MPLS augmentation > > carries additional mpls specific data. > > > There are signaling control plane protocols specific to exchange > MPLS > > labels (e.g. RSVP-TE, LDP) which I expect will exist at > > /routing/control-plane-protocols/control-plane-protocol (e.g. > > draft-ietf-teas-yang-rsvp) > > > > Tarek > > > > Yes, so BGP is out of line, but that is a problem for another WG. > > > > The MPLS quirks are IMHO twofold. > > > > Why define an address family? I always think of AFI/SAFI when > someone > > says address family and I do not see MPLS figuring in that > context. > > [TS]: MPLS can augment routes in the V4/V6 AFI routing tables defined > in RFC8349. However, there are other type of MPLS routes > (cross-connects) that are not associated with an IP prefix or an AFI > defined in RFC8349. Examples of such routes can be RSVP-LSP > labels/cross-connects, per L2 or L3 VRF de-aggregation labels, etc.).. > Such routes will exist in the new MPLS AFI table. > > > > Second, what are MPLS and MPLStunnel doing in the Interface Table? > Ok, > > they are a carry over from the MIB but do they have any role here? > > [TS]: currently, this is enabling MPLS on the specific (sub)set of > interfaces and setting minimal set of attributes - e.g. MPLS MTU. > > > > I am fishing for some 'when' (or if-feature) statements alongside > the > > 'augment' > > to make the augment conditional (although perhaps not as many as > TEAS > > created:-). Instinctively I feel there should be something as > e.g. OSPF > > has although accepting your point about MPLS not being a protocol; > but > > then mpls-ldp is a protocol but has no conditionals that I can > see. > > [TS]: I think the assumption was MPLS is a base functionality that > most router vendors will support - so we've avoided an if-feature check. > However, I can see that some devices may not support MPLS (or may not > turn MPLS), so we can look into adding a when or feature check to > control augments to external YANG models. For MPLS LDP, yes, I think > they can add the same for signaling MPLS. However, I am aware LDP > protocol can be used for non-MPLS signaling too (e.g. ICCP) - so the LDP > YANG modeling team may need to look at what augments can be > controlled/associated with MPLS. > > > > At a slight tangent, I see in OSPF and others references such as > > container mpls { > > description "OSPF MPLS config state."; > > container te-rid { > > if-feature te-rid; > > ie conditional but not on MPLS per se. > > > > [TS]: Yes, although traditionally enabled for MPLS-TE, the TE > router-ID can apply to non-MPLS technologies too (e.g. for GMPLS OTN, > etc.).. IMO, Ideally this would not need to exist under mpls container.. > We may need to raise this with OSPF team. > > > > Regards, > > Tarek > > > > Tom Petch > > > > > Regards, > > > Tarek > > > > > > -----Original Message----- > > > From: tom petch <ietfc@btconnect.com> > > > Date: Tuesday, November 13, 2018 at 7:37 AM > > > To: Tarek Saad <tsaad@cisco.com>, mpls <mpls@ietf.org> > > > Cc: "draft-ietf-mpls-base-yang@ietf.org" > > <draft-ietf-mpls-base-yang@ietf.org> > > > Subject: Structure of draft-ietf-mpls-static-yang > > > > > > I wonder if the IETF has yet worked out how to model routing > > protocols. > > > I asked, what is MPLS? Looking at various modules, I see > > > > > > RIP > > > augment > > /routing/control-plane-protocols/control-plane-protocol: > > > +--rw rip > > > +--rw interfaces > > > > > > OSPF > > > augment > > /routing/control-plane-protocols/control-plane-protocol: > > > +--rw ospf > > > +--rw areas > > > | +--rw area* [area-id] > > > | +--rw interfaces > > > > > > the other IxxxGP > > > module: ietf-ixxx > > > augment /routing/ribs/rib/routes/route: > > > +--ro route-type? enumeration > > > augment /interfaces/interface: > > > +--rw clns-mtu? uint16 > > > augment > > /routing/control-plane-protocols/:control-plane-protocol: > > > +--rw ixxx > > > +--rw enable? boolean > {admin-control}? > > > +--rw system-id? system-id > > > +--rw area-address* area-address > > > > > > BGP > > > augment "/routing-policy/defined-sets" > > > module ietf-bgp { > > > +--rw bgp! > > > +--rw global > > > +--rw afi-safis > > > +--rw afi-safi* [afi-safi-name] > > > +--rw ipv4-unicast > > > +--rw ipv6-unicast > > > +--rw l3vpn-ipv4-unicast > > > > > > PIM > > > module: ietf-pim-base > > > augment /routing/control-plane-protocols: > > > +--rw pim! > > > +--rw address-family* [address-family] > > > | +--rw address-family identityref > > > | +--rw <per address family configuration> > > > +--rw interfaces > > > +--rw interface* [name] > > > +--rw name if:interface-ref > > > +--rw address-family* [address-family] > > > > > > MPLS > > > > > > module: ietf-mpls > > > augment /rt:routing: > > > +--rw mpls > > > augment /routing/ribs/rib/routes/:route: > > > +--ro local-label? rt-types:mpls-label > > > augment > > > > > > /routing/ribs/rib/routes/route/next-hop/next-hop-options/simple-next-hop > > > : > > > .... > > > identity mpls { base address-family; > > > > > > Different! which is right? Perhaps none of them. It is > very > > early days > > > for routing YANG modules, no RFC, limited experience. I am > > mindful that > > > it took several years after the publication of the initial > system > > YANG > > > modules for the advent of NDMA - a radically different > approach - > > so > > > perhaps in a few years we will be looking at the routing > modules > > and say > > > it needs a different approach. Sigh > > > > > > Tom Petch > > > > > > > > > > > > > > > > > > > > >
- [mpls] I-D Action: draft-ietf-mpls-static-yang-05… internet-drafts
- Re: [mpls] I-D Action: draft-ietf-mpls-static-yan… t.petch
- Re: [mpls] I-D Action: draft-ietf-mpls-static-yan… Tarek Saad (tsaad)
- Re: [mpls] I-D Action: draft-ietf-mpls-static-yan… Tarek Saad (tsaad)
- Re: [mpls] I-D Action: draft-ietf-mpls-static-yan… tom petch
- Re: [mpls] I-D Action: draft-ietf-mpls-static-yan… tom petch
- [mpls] Structure of draft-ietf-mpls-static-yang tom petch
- Re: [mpls] Structure of draft-ietf-mpls-static-ya… Tarek Saad (tsaad)
- Re: [mpls] Structure of draft-ietf-mpls-static-ya… tom petch
- Re: [mpls] Structure of draft-ietf-mpls-static-ya… Tarek Saad (tsaad)
- Re: [mpls] Structure of draft-ietf-mpls-static-ya… tom petch
- Re: [mpls] Structure of draft-ietf-mpls-static-ya… tom petch