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