Re: New Version Notification for draft-petrescu-6man-ll-prefix-len-17.txt
tom petch <ietfc@btconnect.com> Wed, 15 May 2019 09:44 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA6F1200BA for <ipv6@ietfa.amsl.com>; Wed, 15 May 2019 02:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, 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 aNAZyXzQBPyu for <ipv6@ietfa.amsl.com>; Wed, 15 May 2019 02:44:00 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50091.outbound.protection.outlook.com [40.107.5.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5CE1201C5 for <ipv6@ietf.org>; Wed, 15 May 2019 02:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GOzW+z49lsE/2aA2Ps7el3gPPUfszs0bI9rc1Klqxj4=; b=fcDvEjgTwtTJnP2COsq0zZWXrPJwTpH7Jdyr5ff5scU1hRJcnI8k2+jT7yoFv6APrzBGd2/ZQjT1+stscx6HpWvQT4z/Npnb4QgH2+X/cDsOi3qNkp7rPi0gLfv/X9Zn/4M3KlO6NX8QncSieUuy3vlypzk5KhJkwqq65g7szXg=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB6077.eurprd07.prod.outlook.com (20.178.124.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.7; Wed, 15 May 2019 09:43:57 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1900.010; Wed, 15 May 2019 09:43:57 +0000
From: tom petch <ietfc@btconnect.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: "sthaug@nethelp.no" <sthaug@nethelp.no>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: New Version Notification for draft-petrescu-6man-ll-prefix-len-17.txt
Thread-Topic: New Version Notification for draft-petrescu-6man-ll-prefix-len-17.txt
Thread-Index: AQHVCjdRJUefvAov1kiHQ9PpvZGL0g==
Date: Wed, 15 May 2019 09:43:57 +0000
Message-ID: <013201d50b02$30c11ce0$4001a8c0@gateway.2wire.net>
References: <3aca6800-8b3e-8a0e-eacb-2cd8eceddbb9@gmail.com> <20190513.115657.485273190.sthaug@nethelp.no> <CC44D89A-9002-4807-B43D-408B6B81D315@gmail.com> <20190513.163247.474361422.sthaug@nethelp.no> <026d01d50a36$cb95c6c0$4001a8c0@gateway.2wire.net> <CABNhwV10pThni1Y0a5NP2UrJJuEP9mLj=BTB8j48dkFfurKuYw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P123CA0007.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::19) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 94de32f0-1839-4475-2e09-08d6d919d98b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB6077;
x-ms-traffictypediagnostic: VI1PR07MB6077:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1PR07MB60777F1E8F6FACA88AC77B8CA0090@VI1PR07MB6077.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0038DE95A2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(396003)(136003)(189003)(199004)(13464003)(86152003)(9686003)(7736002)(6512007)(2906002)(6306002)(66066001)(486006)(45080400002)(256004)(86362001)(15650500001)(71200400001)(71190400001)(14444005)(5660300002)(6246003)(53936002)(62236002)(44716002)(66574012)(476003)(1411001)(1556002)(446003)(81686011)(81816011)(76176011)(102836004)(61296003)(26005)(305945005)(50226002)(966005)(229853002)(15974865002)(44736005)(14454004)(53546011)(6916009)(478600001)(6506007)(386003)(52116002)(68736007)(6486002)(84392002)(186003)(66446008)(64756008)(66556008)(66476007)(66946007)(73956011)(25786009)(8936002)(81156014)(81166006)(14496001)(6436002)(316002)(4720700003)(8676002)(54906003)(4326008)(6116002)(99286004)(3846002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6077; H:VI1PR07MB3118.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: IqaDg7h3SW+1QxhHsBPVJ0WTFEADVXTRhj3XwXF33eRL833QawG5fQJVEdnDMlJ9xyivDqkbYEq36LBuXntLhtfSPAJueuBiGWmfU0NBDM3+0Xmr2wbGKSs7oFS/fyL0C0DdUrqQQ02kCdJKPBjmsKz7L7jRQ0r9+B0N6ubn/vLurkIutbSYIbvz+v0ybLb6tASvX57LO6LYt11oZ3RqeIyrVURbulJB8+6zTqaLul7pG2AWAWEKfiXbBTlfJ3ZnHAMNxGxkWEmZqIMBdPrSjJLL5ER7HSVHm1L4ZUvCA0O1eLepQ+NIjo23Dc8lzKjUJiYVntIsMrz7h4YNAg0SL1f2nuaiWaM/F4kCqPnQy+B85aLRegg/krCuAVBryFE5pfMVB9MDC3xrOIbAvV0SEsybfW2vHV3fKJbc73tskuE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <81BD97987739794680831393BC8E1B4C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94de32f0-1839-4475-2e09-08d6d919d98b
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2019 09:43:57.4016 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB6077
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZsWITEqK9sU--EFvkeqLeoH2UF8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 09:44:03 -0000
----- Original Message ----- From: "Gyan Mishra" <hayabusagsm@gmail.com> Sent: Tuesday, May 14, 2019 11:10 PM The 32 bit router id for both ospf & ldp & te was defined as such based on the IPv4 address 4 octet notation with no bearing on size of the network that we would have even 2^32 = 4.2 billion routers in a network. <tp>wrong; the 32 bit router id for OSPFv2 was defined as a 32 bit field with no semantics. As RFC2328 says " A 32-bit number that uniquely identifies this router in the AS." In some implementations, it is derived from an IPv4 address but that is a (unfortunate) quirk of the implementation; other implementations are more flexible; the 32 bit OSPFv2 TE router id is defined as a reachable IPv4 address; the 128 bit OSPFv3 TE router id is defined as a reachable IPv6 address So same reasoning for having a router id that is an IPv6 address since at some point in time IPv4 will be legacy long gone so the router id has to be based on ipv6 in the future. <tp> wrong a router id is not an address, not IPv4, not IPv6 not any protocol So well before IPv4 is long gone we need to have a router id for all routing protocols that supports using an IPv6 address 128 bit length. Not that we would never have an OSPF or MPLS network that has 2^128 routers but that we need to be able to support a router-id that is now based on IPv6 addressing as well and not just IPv4 for the future elimination of IPv4. <tp> wrong; a router id is not an address; a TE OSPFv3 router id is an IPv6 128 bit address. I agree that we are unlikely to need 2^128 different router ids - 2^32 will likely be enough for the foreseeable future so a 32 bit router id will likely see us through I understand that per Yang model that both ospfv2 & ospfv3 IPv4 & IPv6 address families both use 32 bit number dotted notation <tp> YANG defines a lexical format for its types; where this is 32 bit, it uses, and, sensibly, reuses, the concept of dotted quad which says nothing about the semantics of the 32 bit That really has no bearing or prevents any network from going IPv6 having an IPv4 router-id. The IPv4 router-id is OK with dual stack but once IPv4 is eliminated then it becomes a problem primarily for MPLS LDP. <tp> wrong; a router id is not IPv4 or IPv6 or any other protocol - it is a router id Also the router-id technically does not have to be routable for IPv4 but does have to be routable for LDP for link & targeted LDP for LDP to work so in most ospf deployments the router-id best practice is to always be routable. <tp> the router id does not have to be routable, ever, which is why there is a separate TE router id which does have to be routable, IPv4 or IPv6 depending on context once you move to an IPv6 only network technically and IPv4 is gone even for MPLS LDP IPv6 today supports a dual stacked MPLS core but now once IPv4 is legacy and removed from the network the IPv4 router id will no longer be routable and LDP will be broken. <wrong> the router id is a 32 bit number which is neither IPv4 or IPv6; where a routable address is needed, then the protocols specify the TE router id which must be routable, IPv4 or IPv6 With OSPFv3 technically you are ok and can stay with a 32 bit 4 octet router-id but for MPLS you cannot and the MPLS WG would have to come up with a draft for IPv6 based router-id once IPv4 is eliminated from the MPLS core. <tp> MPLS, and TE in general, defined the TE router id for this purpose many years ago so no, the MPLS do not have to come up with a draft - there is already an RFC. HTH Tom Petch Gyan On Tue, May 14, 2019 at 5:27 AM tom petch <ietfc@btconnect.com> wrote: > ----- Original Message ----- > From: <sthaug@nethelp.no> > Sent: Monday, May 13, 2019 3:32 PM > > > > I agree that we need an IPv6 router id 128 bit expanded field > > > > Why? I really doubt you're planning more than 2^32 routers in your > > OSPF infrastructure. > > > > > and even now with the IPv6-only flag draft of which Microsoft and > maybe other vendors are getting on board as major players that > enterprises can definitely deploy managed networks to IPv6 only in the > access side and use 6to4 nat 6to4 dns and 6to4 proxy for internal and > external IPv4 resource access. > > > > There is no connection between IPv6-only and 32 bit OSPF router ID, as > > far as I can see. A 32 bit OSPF router ID won't prevent you from going > > IPv6-only. > > Absolutely. RFC8294 defines router-id as > "A 32-bit number in the dotted-quad format assigned to each > router. > (note: dotted quad - a convenient way of writing, reading, speaking ... > a 32 bit number which carries no semantic overtones). > > MPLS, traffic engineering and such-like require a routable IPv4 or IPv6 > (or both) address and those are specified separately and are commonly > referred to as te-rid or Traffic Engineering Router-ID - see for example > draft-ietf-ospf-yang > > So I see no problem that was not solved many years ago. > > Tom Petch > > > Steinar Haug, AS2116 > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile – 202-734-1000
- Fwd: New Version Notification for draft-petrescu-… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… Nick Hilliard
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… sthaug
- Re: New Version Notification for draft-petrescu-6… tom petch
- Re: New Version Notification for draft-petrescu-6… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… Ole Troan
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… Alexandre Petrescu
- Re: New Version Notification for draft-petrescu-6… sthaug
- Re: New Version Notification for draft-petrescu-6… Mark Smith
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… sthaug
- Re: New Version Notification for draft-petrescu-6… tom petch
- Re: New Version Notification for draft-petrescu-6… Gyan Mishra
- Re: New Version Notification for draft-petrescu-6… tom petch