Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts
Haoyu Song <haoyu.song@futurewei.com> Wed, 16 November 2022 18:04 UTC
Return-Path: <haoyu.song@futurewei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF270C14F737 for <idr@ietfa.amsl.com>; Wed, 16 Nov 2022 10:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSkDUcjKsEog for <idr@ietfa.amsl.com>; Wed, 16 Nov 2022 10:04:06 -0800 (PST)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20725.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eb2::725]) (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 138DDC14F6E5 for <idr@ietf.org>; Wed, 16 Nov 2022 10:04:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jAic5NkAFQUbsOzHBBSTFwNJDMCGXRoVDYHNMo0T8WpeS/UtbnrkwADi6spG2QabgjhmT8ZEY4q8JnT36DnKToFKz9N2xmdazCbpPv7i4sW9gZ6FOF12sW4Do6oNDCZD52DH0N7daPBrqgwTBR7eSRgfrNcIMSk16Vu49Jn2wZ/Q1DButI6o6BMgDdAlaQcE/eji8kvZEbB4sSrpFX7OPxNO9xct7oKrNk6JhMUeZ1V7m0aLhDaayrhwojRkQYY7PKrMA0ARmg6PF2/2KQJtVyMdNsdlSHAaYPOK5p5Hg4aYld1sDvpOWUO7jIcK8jzajbQlT67wCvkMimejPXF++Q==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jzq7zAwfn0nf9iJ0c8Z66fFOew9qaw6Y9ZCtraVapBo=; b=dy8SlMxSygp2iKBtijTmfK5mZEpiw2ppzcSNK5RJfIJcM6TBzJHfhrLKZLJQBP+4zUUWKwwJmI6tEYM7UkkSlmVqh2lX/5Nl5BI4CSPB/yYgjIKJ8Uwg9IkhRJpsoK8JkVT5fB5VCGVOi9LYgE94RB9uEAWxu/ZJ/q+WS4ZmN7T5vOBoH3i2pRstho8ePr40GuH8myIdsJCvoVIZwfa8+ZSld+RQ/JPWHVDnl6BqUx4GjfqEREqM9e2/2lqwmNhvw1c0j3dmqKj4yJcklb9CwyOyHN/TpKEHO1oV/YLUSgVXxXQK2KxwKXQLDQSKOhpjxfHt9b5VJAzLiru2vuUF5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jzq7zAwfn0nf9iJ0c8Z66fFOew9qaw6Y9ZCtraVapBo=; b=DLE0oihVcPSf0318FNSnZWyFPt4twA7KXEuzDqVodXmI2Btr5jbZQHUUwMDZPwpDTGNqnnRtb2kz6HuVnDbYGOLD2Nx9n/U2U5s0CgVcLYAs1DE4Zx9nDjpXbKuIZy/nv27yUfAmPHkFrS5rqhpmVL1688dROolqhBUnwf3tQnI=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BY3PR13MB4865.namprd13.prod.outlook.com (2603:10b6:a03:36c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.18; Wed, 16 Nov 2022 18:03:57 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::f80f:2d0c:29fe:47b2]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::f80f:2d0c:29fe:47b2%5]) with mapi id 15.20.5813.019; Wed, 16 Nov 2022 18:03:57 +0000
From: Haoyu Song <haoyu.song@futurewei.com>
To: "idr@ietf.org" <idr@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>
Thread-Topic: [Idr] [bess] Suggestion on v4-only/v6-only drafts
Thread-Index: AQHY+eXLWbMs+HPDa0qZ9948psvF6Q==
Date: Wed, 16 Nov 2022 18:03:56 +0000
Message-ID: <BY3PR13MB4787A1D29D0DE4A7416266EA9A079@BY3PR13MB4787.namprd13.prod.outlook.com>
References: <mailman.474.1668559095.13241.idr@ietf.org>
In-Reply-To: <mailman.474.1668559095.13241.idr@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY3PR13MB4787:EE_|BY3PR13MB4865:EE_
x-ms-office365-filtering-correlation-id: 22fcd0e8-3e5f-40a5-a293-08dac7fcee42
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: A6q4MjDQ91uKqCRt+h0PDlXSllBq02A2H1t1sxIfofURNiGdoSvcUbb9mJAL1OH69UH1aNGx3xiweysLQMAfRBlTBsyCNY19FDbjkV04hXUvS9Yco1PEN6gX48EDylFP71O6HKME/0zyncmZsKmzsAMxLGlRv44QJPV6564luxYjh36Yann4RU7q6KIAUWwFH+uxElfw5vsiYU5gLY5OHYNZ70X2v51Blhau6BIxtY/0NvqDVi9oWMKaHJD28vRhhQkSv2k7Z/7Znrz1f7B9o1DPxHWB/lhKVlTgM6Ijt5Yr5L5Lqr8XsFnHIsjJghUArXIBcMeTmQUR2073u2eHq1e9Dk6cvtIApLssH3Z2490fniKGnHs7RfeYh8YWgWjmlKGNBqF3tN2GpIv042F6HXYAjd4ea0HTU5h7olkBf9D45JEWnJ7u92IlmOb24AUy6oSNANAvZ4oKZXcAzD9ALTkgaT1HTpL/Oj5L+mmnMXRe+6nPljJf8I5Fexb3ausDGb4GvvGpbYemBtFoclKxO6KTHlJM+tnsSNFyvRXUdDH5Qb//Y1PxMYzQUv2Fih2YRcq2d7lkwfaL/0nyh3gh7fAPKWF9Eiv6riDZWkMoh2BEvKu+G30otLQx2z+OHnEePmzWe7033DauqZpKyNL5j80EXCCbSaqsURhcyZd2vRu5Qe+OvhHudSp2MZrz2WfXBS9mnS25xyi5TA0H202hg36ox1yjtcEqc1pYMvZ8jNNonCQ3wlHnUOzeyZAbOR537eWR0ZUok7sTkb/hW12ott+G+ZK95Y97jqGsZ0P5Z8IBNPj0AKzn9yJ8JlvYs0WaRVKiLGaoFIUvlOzclw7dgggRzU9X04ZP6bmJR2D3WTzIWyiPLWwyjks8F52p4jY6
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(396003)(136003)(39840400004)(366004)(346002)(451199015)(478600001)(71200400001)(966005)(45080400002)(66899015)(26005)(110136005)(6506007)(316002)(66476007)(52536014)(66446008)(64756008)(66556008)(7696005)(8676002)(66946007)(41300700001)(8936002)(30864003)(44832011)(186003)(40140700001)(5660300002)(2906002)(76116006)(9686003)(55016003)(38100700002)(86362001)(83380400001)(66574015)(33656002)(122000001)(53546011)(38070700005)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 33SWpwG3lP7ZiQKFubYpMaRw0lCdnm0AQUrIBdZAM+6yEc++gjsbylhs3l8SatlApMNrUSlyJV4OTXukijThhFnS1R3lCX2Gd760RxRA7sKKupaqW+3W07bNoaWWv7ilMUNV2Qo7i444eT5DALTjSyltsCTHgVDFwdmBGrV6VgqIMg2kNH2p883SkedlVw3Mm92gK9akbeSrV6k1Hte98RtTa7LQWy6MMa7ucgXTcPRw5cyQAMwCMEZ0Sn0UAZuM5iaUAAhnDSwZxBNAETSIQcICl9NLujRgphfkpfqQJf+AuJj+D/LvdjlQjcOWzoRqeHQTbx4kthPoCEF2hvy8udlXfVr1bjZ41VYMV41a8UJ9yabz23a0Np1pfDZqmwxKlNRv+RclOrfk0X5F6K2emfIfqEVQCZ8+/9NECVvlPz03nFh1hpHKTQewIB61PTo5tg3fJy+VivsD5WqBkt/sDGgfGjxljE5BMJOzQ74ypZ++vZHS4EY9Lyf7wh6tOJBLrjp8uP3475DUiWTLKurNiMOPlAkJZ1TYefRt0dFHfIMQIZ121E/S1mCtYNS7lHuClE/v+5heeo70ChepN8Wg5sbZ64o6OUpE0BBg6/0S+FI7xUQc3ajmyZoCsHZ91X9wMLQODaWd485AXIKHF+Hk+phSuSX238IxbolGQ7fbZnJAI+oZZWoWzxf8hNzqJFMmCZMD7OzUXSVSNE4lm5SMYDlXagbGBWCGSv5FTZBY3PCZJyYFE5Y3AOTOa3LDu7MZmapUwyY0cI3hQUuBFGHqLJaA6ddICyz3nuiEDH7Dq3TUay/TcNM9I9bKpaLdt26xHEt08TS9IBEysQ6DqBjMrnKIJryktHJ6pZWzLAelcB1X4Cbq74YIYkmq0WFVuJkyxKAbULgyjul2uawMi8S2pU+naPy2GjyQhmcSOAZaYXHIRp3vCva5gCLsd3qL89ljqdKMtSU0aGAMHvyV3LSW3AeRA69QX2ytFgzllhzDBk92FLeLRmlwrm2vowgd628KsPXO2P+NvekeIoiTKrY3bdcxuq3xtDuZIMTFxRIOWXeRL0HzNmNtueUVXVB9MTnS6+R2OtxmyBPLtE7tVg+TfuFIOTN2b7+l0Kz6gshdorY38MH439bmysdiVaq1YLjy8m67Z6zKWQ4GQYPo/OxoZvQ8uxyHdEgyQY4P6GfIpRlMdDPmJ/gQ8nt5p0GmgjpSPlJz7yhjVdBoWojhVAjpsSOlrotBjsiG51JCUHH6AFNG5E+1sPNy+WIMMX2aaYWr4ZEAGvDQo0p2CVLkHvZWGvElut41t3AoevMzWMjdgXIgm3u1wpxmv2UIhTzRwLXIrIAjrHk0xN/YiQtShDuC9Qu+5JV7a3GgT1n3zhTUIZkNPMhDMPgWHyCC8oEqzyzlAVQNq2upKM0/Bb8j8eUuqtePtJH7qJd+ODm7y9dRZ91sYjZdAU73QnyExgCsGp2HqIB8lJlAAEGMwlxat+6ZLogbBljusJH0HVIqwVoOiO8KdYBHC9DQ0zqQnSbuUi+Rel9GkHUqPAPAxUVJNa61p3lCWWs9w08G85Xgf3QJoQE=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22fcd0e8-3e5f-40a5-a293-08dac7fcee42
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2022 18:03:56.8908 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MpGzKmiDp6iTBemBPreQTuzgF/fMjq06rbekUi7fzCEiGs34u84aPU7GQSCJINyk7X9JFjvJdgjJi16N4nXI5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR13MB4865
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TQOLz7J-JvOOR0CLEhAs96xhii0>
Subject: Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2022 18:04:11 -0000
Hi Gyan, I have read the draft and support to move it forward. Thanks! Best regards, Haoyu ---------------------------------------------------------------------- Message: 1 Date: Tue, 15 Nov 2022 19:37:57 -0500 From: Gyan Mishra <hayabusagsm@gmail.com> To: Huaimo Chen <huaimo.chen@futurewei.com> Cc: "idr@ietf. org" <idr@ietf.org> Subject: Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts Message-ID: <CABNhwV19D-0Ab01R5vq0o44ENsD3BKTdc2CkKZP2obYjg9VrJQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Huaimo Thank you for the feedback I will fix and update accordingly in the next revision. Thank you Gyan On Tue, Nov 15, 2022 at 12:34 PM Huaimo Chen <huaimo.chen@futurewei.com> wrote: > Hi Gyan, > > The draft is useful and should be moved forward. > > I have the following comments: > 1. On page 5, in the paragraph starting with "The 4PE router > receiving ...", it seems better to rephrase the definition of Egress 4PE router. > 2. On page 10, there are two paragraphs starting with "In the 4PE > design over ...", it seems better to merge or simplify them. > 3. On page 10 and page 11, there are following sentences: > The "FUNCTION" part of the > SRv6 SID now carries the overlay 4PE BGP-LU IPv4 Labeled prefix ... > It seems better to change "FUNCTION" to "ARGS" > > Best Regards, > Huaimo > ------------------------------ > *From:* Idr <idr-bounces@ietf.org> on behalf of Linda Dunbar < > linda.dunbar@futurewei.com> > *Sent:* Monday, November 14, 2022 5:10 PM > *To:* Gyan Mishra <hayabusagsm@gmail.com>; Igor Malyushkin < > gmalyushkin@gmail.com> > *Cc:* Robert Raszuk <robert@raszuk.net>; idr@ietf. org <idr@ietf.org> > > *Subject:* Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts > > > Gyan, > > > > I think the draft is beneficial and deserves to be adopted by WG. > > > > Just have a few questions: > > > > - Does the IPv6 ingress router?s IPv6 address visible to any nodes > within IPv4 islands? > - Page 5 says ?the 4PE routers convey their IPv6 address as the BGP > Next Hop for the advertised IPv4 prefixes. Does it mean routers within the > IPv4 domain see the IPv6 address as NextHop? How do IPv4 routers forward > based on IPv6 addresses? > - When the IPv6 core is SRv6, how does the IPv6 ingress node determine > the Func and Arg for the packets entering the SRv6 domain? > > > > Linda > > > > *From: *Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra < > hayabusagsm@gmail.com> > *Date: *Sunday, November 13, 2022 at 8:09 PM > *To: *Igor Malyushkin <gmalyushkin@gmail.com> > *Cc: *Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" > <idr@ietf.org> > *Subject: *Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts > > > > Hi Igor > > > > This was a really productive discussion and thank you for all of your > feedback and comments on the draft. > > > > Responses in-line > > > > On Sun, Nov 13, 2022 at 4:18 PM Igor Malyushkin > <gmalyushkin@gmail.com> > wrote: > > Hi Gyan. > > > > > Thank you for the detailed explanation! > > You are welcome :) > > > So this is an optimization that can apply to 6PE and as now as we > develop 4PE add this option where you have a single CE next hop label > for the bottom of stack label but then you don?t have to label all the > CE prefixes and can keep unlabeled. > > > > > > Precisely. We've done it for 6PE to achieve fast convergence among > other things (also for IPv4 too but the core was IPv4 native). > > > > Gyan> Excellent! I see, so for native IPv4 core prefixes where you > are doing global table native IPv4 to the CE edge also applying same > concept instead of labeling all the CE IPv4 prefixes just label the CE > next hop prefix so you have a 2 label label stack. > > > > Could this optimization be applied to all the 4PE inter-as option B > and C where the PE address is labeled only instead of all the prefixes? > > > > Most Excellent! Great optimization! > > > > > > Actually, my curiosity about EPE wasn't useless. You have asked me to > show you where vendors implement 6PE over IPv6 unicast. Please, note your link: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopic > s%2Ftopic-map%2Fbgp-egress-traffic-engineering.html%23id-configuring-e > gress-peer-traffic-engineering-by-using-bgp-labeled-unicast-and-enabli > ng&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64 > d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155928 > 3381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OrO9M2UBYo%2B8o > rqdBTVUZnM9JJUaybApZafQ97DFGHE%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopi > cs%2Ftopic-map%2Fbgp-egress-traffic-engineering.html%23id-configuring- > egress-peer-traffic-engineering-by-using-bgp-labeled-unicast-and-enabl > ing&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd6 > 4d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6380415592 > 83381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OrO9M2UBYo%2B8 > orqdBTVUZnM9JJUaybApZafQ97DFGHE%3D&reserved=0> > > > First, as you can see they advertise some ARP routes which are based > on BGP peer address (egress-te knob, I consider it a very inflexible > way to advertise next-hop based route, Nokia does the same, but we > have that we have). So that is exactly what I supposed with LU routes > for NH but not for prefixes themselves. Second, they advertise IPv6 > reachability over IPv4 sessions via the IPv6 unicast family (to > preserve the original next-hop) and the ARP route over IPv6 labeled > unicast family. So, this is an example of 6PE with IPv6 unicast I believe. > > *Last but not least advertising tons of IPv4 LU can create some > problems with filtration/leaking between unicast RIB and the Tunnels > Table (note they use rib inet.3 for all BGP LSP which is good).* > > > > Gyan> I just read it and I see the IPv6 unicast 6PE carried on BGP-LU EPE. > Are you saying the ARP routes in inet.3 for BGP LU EPE /32 or /128 > routes is the CE next hop connected interface host routes for MPLS > forwarding. I agree and this is identical to how Cisco does it same > ARP routes for BGP-LU for inter-as options B and C and BGP-LU EPE > using a host static route. I think that is semantically the same as > what you described as ?CE address next hop? arbitrary labeling concept > to create that service label 2nd level in the label stack - and then > not have to LU advertise all the v4 or v6 prefixes as labeled and just use 1/1 or 2/1 unicast SAFI. > > > > I agree and I have seen SAFI 4 and 1 in the same RIB with Cisco and > other vendors making filtering and troubleshooting more complex where > Juniper separates SAFI 1 and 4 into separate rib inet.0 and inet.3. > > > > I think at a minimum we want the two-level label stack. > > Yes. But I want you to pay attention to the "Option C" case. Inside an > operator domain (if we don't stitch BGP LSP to something else) there > will be three labels and the bottom one will be absolutely pointless > (ok, PE can advertise "3" for IPv4 LU routes here but anyway). > > > > Gyan> For Option C you would AFIK you would have a 2 level label > stack transport label BGP-LU and the service label which could be > either label all IPv4 prefixes as described in the draft or just the > PE inter-as link address and advertise all the prefixes unlabeled. I > think in that case is you as well labeled all the prefixes as well you > would end up with a 3 level label stack not desirable agreed. So in > the draft scenario or in your CE address only labeling scenario you > end up with a 2 level label stack. > > > > > This can be alleviated of course with explicit null. > Actually, I consider 0, 2, and 3 are harmful. Why don't we always use > arbitrary labels nowadays? But it's my personal pain. > > > > Gyan> With L2 or L3 VPN you have at a minimum minimum of 2 label > label stack. If you do global table native routing SAFI 1 MPLS then a > single label label. With FRR or LFA/RLFA/TI-LFA you end up with > additional labels 3+. The depth of the label stack is not the issue - > it?s moreso LU on every prefix scan be problematic. I think arbitrary > labeling next hop CE address label makes sense and provides a great > optimization. Seems very similar along the lines of VPN per-VRF of > per-CE label allocation modes optimization as compare to per prefix. > > > > Thoughts? > > I'm glad that the 4PE document will be more flexible than the 6PE. > > > > Gyan> Thanks again for all the detailed comments and feedback. > Yes as you have pointed out I agree and will make 4PE more flexible. > > > > But I still think that at least I as an engineer have all the > necessary documents for 4PE. > > > > Gyan> Perfect! > > > > But if you want to build the new document around the "two labels" > pivotal I'm not against it. > > > > Gyan> I will update this draft in the next revision. > > > > I will add the 4PE optimization- arbitrary style per CE next hop > service label connected interface ARP route and not labeling service > prefixes advertised for intra-as and inter-as 4PE. So we will have > net-net change is the existing draft option plus your option. I will > make the two options a Should normative language flexibility. > > > > Would you like to join the draft as co-author? > Thank you for that opportunity, but I prefer to be a spectator :) > > > > > > > > Gyan> Many Thanks for all your feedback! > > > > ??, 13 ????. 2022 ?. ? 22:38, Gyan Mishra <hayabusagsm@gmail.com>: > > > > Hi Igor > > > > Thank you for the detailed explanation! > > > > So this is an optimization that can apply to 6PE and as now as we > develop 4PE add this option where you have a single CE next hop label > for the bottom of stack label but then you don?t have to label all the > CE prefixes and can keep unlabeled. > > > > I like it and thank you for bringing up! > > > > I can update the draft with this option and we can make it part of the > standard. > > > > We can relax the relax the BGP-LU 1/4 option and can state both two > level label stack options and if there is any other permutations we > can add to the draft as well. > > > > I think at a minimum we want the two level label stack. > > > > I don?t think we want a single level label stack as the issue > mentioned with exposed IPv4 packet hitting a IPv6 P node and being > dropped. This can be alleviated of course with explicit null. So I > could add this as an option as well but with the requirement of explicit null. > > > > Thoughts? > > > > Would you like to join the draft as co-author? > > > > Many Thanks! > > > > Gyan > > > > On Sun, Nov 13, 2022 at 2:49 PM Igor Malyushkin > <gmalyushkin@gmail.com> > wrote: > > Ok, please see my explanation below. > > > > ??, 13 ????. 2022 ?. ? 21:12, Gyan Mishra <hayabusagsm@gmail.com>: > > > > Hi Igor > > > > In your last response I did not see a comment on the section > highlighted excerpt below where I mentioned the protocol mismatch > where on the PHP node when the label is popped it other then the QOS > EXP scheduling issue as well it exposes the native IPv4 packet that > that cannot be forwarded as the core is IPv6 only. The workaround is > you could do explicit null pipe mode to retain the topmost label, > however the implicit null PHP should indeed work as well on its own without having to use explicit null. > > > > That is the reason for labeling the IPv4 prefixes being tunneled. > > > > Please share your thoughts and comments on below and I am responding > to your last email. > > > > Except below > > > > How would you have 2 labels in the label stack if you use SAFI 1 1/1 > IPv4 Unicast as that would be ?native IPv4 packets? non labeled no MPLS shim. > > [IM] As I pointed out a couple of times we will use a BGP tunnel > toward the NH address of an IPv4 unicast route. So there will be two > labels: one for BGP LSP, and another for LDP/RSVP LSP. > > So as I said before and the reason for the standardization is that if > you don?t label the IPv4 prefixes from the IPv4 island being tunneled > over the > IPv6 LSP then on the PHP node when the transport label is popped > implicit null value 3, the native IPv4 packet is exposed and is > forwarded from the egress P PHP node w/ PHB scheduling broken as EXP > match cannot occur without the IPv4 prefixes being labeled IPv4 LU. > That is a requirement for 4PE to work w/o breaking QOS EXP scheduling > and is the procedure that must be followed for any 4PE implementations. > > [IM] Again, we will preserve two labels. In your case, you allocate a > label for the IPv4 label unicast packet with the customer's prefixes. > I suggest allocating a label for the IPv4 label uncast with the > customer's next hop. In your case recursion is two-level, in my is > three-level. If the P node pops the transport label there still will > be the label of the labeled unicast packet in both schemes. But my > scheme has several benefits and doesn't require to advertise tons of > the customer's prefixes via labeled unicast. I can highlight some more > issues with this, but most of them are vendor-dependent so I'm not > sure that they are applicable to this discussion. And again, both > methods can be deployed depending on the requirements. Also, there are > other possible options, and they can probably have their own benefits. > The problem is in the wording that requires advertising all with SAFI > 4 family, I don't have problems with the requirement of two labels. > > > > So It?s not just breaking QOS EXP scheduling as once the PHP POP > happens on the PHP node for 6PE the native IPv6 packet is exposed and > that cannot be forwarded as the core is a per standard design > following RFC 5545 Softwire mesh framework a single protocol IPv4 only > core so the IPv6 packet is dropped and cannot be forwarded. > > > > As well for 4PE It?s not just breaking QOS EXP scheduling as once the > PHP POP happens on the PHP node the show stopper deal breakers is > that the native IPv4 packet is exposed and that cannot be forwarded > as the core is a per standard design following RFC 5545 Softwire mesh > framework a single protocol IPv6 only core so the then the IPV4 packet > is dropped and cannot be forwarded. > > [IM] These statements are based on the assumption that we can't have > two labels in the stack. As I described above we can. > > > > > > Kind Regards > > > > Gyan > > > > On Sun, Nov 13, 2022 at 3:29 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > > > Hi Igor > > > > Please see in-line Gyan2> > > > > On Sat, Nov 12, 2022 at 7:44 PM Igor Malyushkin > <gmalyushkin@gmail.com> > wrote: > > Hi Gyan, please see the inline. > > > > ??, 13 ????. 2022 ?. ? 01:39, Gyan Mishra <hayabusagsm@gmail.com>: > > Hi Igor > > > > Thank you for your comments > > > > Understood that 4PE has been implemented by most vendors, however a > standards specification has not been written till now and > standardization of this draft would ensure interoperability as many > operators have mix vendor environments. > > > > Responses in-line > > > > Thanks > > > > On Sat, Nov 12, 2022 at 5:31 PM Igor Malyushkin > <gmalyushkin@gmail.com> > wrote: > > Hi gents, > > I found this conversation curious and started reading the document > (draft-mishra-idr-v4-islands-v6-core-4pe-02). First, I skipped the > section about SRv6 because I'm not good at this technology. Maybe the > deal is this section because I couldn't find anything new in the rest > of the document to put it into the Standard Track category. It more > looks like a list of best practices to fire up 4PE in the network. > > > > Gyan> The reason for standardization is to ensure that the process > and procedures implemented by each vendor is the same to ensure > interoperability > > [IM] Could you please describe the process and the procedures? It's > not clear to me. > > > > Gyan2> 4PE procedure is described in detail in section 3 and 4. > > > > Spreading the reachability over BGP with a different next-hop family > is well written in 8950. > > > > Gyan2> Here we are not just spreading the reachability over different > next hops per RFC 8950. > > There is more to 4PE then just the transport tunnel. > > > > Signaling and pointing tunnels toward the next hops aren't new too. > > > > Gyan2> There is nothing special about the IPv6 transport LSP towards > Gyan2> the > egress next hops as that?s is typical to carry and service. What is > critical is the 2 level label stack. > > > > Other things look like the best practices that don't alter any > protocol or technology. Can you highlight what exactly requires standardization? > > > > Gyan2> What we are standardizing with the 4PE procedure is a two level > label stack that you have the topmost transport IPv6 LSP signaling > the egress next hop to carry the service label IPv4 LU prefixes so all > the IPv4 prefixes must have a label binding. > > > > E.g., in the Security section, you state "The extensions defined in > this document...", which extensions? > > > > Gyan2> Sorry that was in error, I will fix in the next revision. > This specification uses existing mechanisms with a new procedure for 4PE. > > > > Of course, 4PE is already a well-known design pattern that has been > implemented in lots of network OS and moreover implemented in > production networks. > > > > Gyan> 4PE is well known however it has not been standardized so this > Gyan> would > make it standard across all vendor implementations > > [IM] It depends on the goal of this "standard". 4PE just as 6PE is the > design-matter thing, we can implement 6PE in several ways with the > standard building blocks (8950 and other things). > > > > Gyan2> The goal of the standard is to have a set procedure for 4PE > that would be standardized. I disagree that 6PE RFC 4798 is a > ?design-matter? thing as it is standards track document and if it were > a ?design-matter? thing there would have been no need for RFC 4798. I > don?t know of any vendor that implements 6PE in several ways. There > has only been one method to implement 6PE and that is following RFC > 4798 which all implementations use SAFI 4 IPv6 labeled unicast 2/4. > > > > Cisco > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm > unity.cisco.com%2Ft5%2Fservice-providers-knowledge-base%2F6pe-with-ibg > p-ios-xr-example%2Fta-p%2F3149743&data=05%7C01%7Chaoyu.song%40futu > rewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1 > d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > 7C%7C&sdata=4m1CXf%2FuEuyuVOoab9x%2BVz%2F934AzbgyPXeOHEzpT3kc%3D&a > mp;reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom > munity.cisco.com%2Ft5%2Fservice-providers-knowledge-base%2F6pe-with-ib > gp-ios-xr-example%2Fta-p%2F3149743&data=05%7C01%7Chaoyu.song%40fut > urewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a > 1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C > %7C%7C&sdata=4m1CXf%2FuEuyuVOoab9x%2BVz%2F934AzbgyPXeOHEzpT3kc%3D& > amp;reserved=0> > > > > Juniper > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fmpls%2Ftopi > cs%2Ftopic-map%2Fipv6-o-ipv4-tunnels.html&data=05%7C01%7Chaoyu.son > g%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b2401 > 89c753a1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 3000%7C%7C%7C&sdata=RanZPiXso2cT8gP%2BdZ9gpuJFf%2B8r616vfdobQRpIIN > 8%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fmpls%2Ftop > ics%2Ftopic-map%2Fipv6-o-ipv4-tunnels.html&data=05%7C01%7Chaoyu.so > ng%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C3000%7C%7C%7C&sdata=RanZPiXso2cT8gP%2BdZ9gpuJFf%2B8r616vfdobQRpII > N8%3D&reserved=0> > > > > Nokia > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Finfo > center.nokia.com%2Fpublic%2F7750SR225R1A%2Findex.jsp%3Ftopic%3D%252Fco > m.nokia.Router_Configuration_Guide%252Fipv6_provider_e-d10e2482.html&a > mp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08d > ac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538 > 075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JeSYnNhr%2BdO8TJNhB > AyR2pRT1aqyUiOaIl%2FHpLYvq7g%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Finf > ocenter.nokia.com%2Fpublic%2F7750SR225R1A%2Findex.jsp%3Ftopic%3D%252Fc > om.nokia.Router_Configuration_Guide%252Fipv6_provider_e-d10e2482.html& > amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08 > dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155928353 > 8075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT > iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JeSYnNhr%2BdO8TJNh > BAyR2pRT1aqyUiOaIl%2FHpLYvq7g%3D&reserved=0> > > > > Arista > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > arista.com%2Fen%2Fum-eos%2Feos-border-gateway-protocol-bgp%3Fsearchwor > d%3Deos%2520section%252035%25204%2520is%2520is%2520commands&data=0 > 5%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64 > %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iQ4qdwwu9EZVw2PQ8E%2BpRNRECT > l1dFXEUKzJUJAO3P4%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .arista.com%2Fen%2Fum-eos%2Feos-border-gateway-protocol-bgp%3Fsearchwo > rd%3Deos%2520section%252035%25204%2520is%2520is%2520commands&data= > 05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea6 > 4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iQ4qdwwu9EZVw2PQ8E%2BpRNREC > Tl1dFXEUKzJUJAO3P4%3D&reserved=0> > > > > Please sent me a link of proof of a single vendor that has implemented > 6PE using IPv6 unicast? > > > > Personally, I'm not against having a BCP document that combines > everything about 4PE together if the authors want to perpetuate the abbreviation. > > > > Gyan> I think the process and procedures can be standardized with the > normative language as written to ensure vendor interoperability. > Existing mechanisms are used however the draft defines procedures to > be followed and that is what would be standardized. > > [IM] Again, I believe we should clarify the point where interop issues > can arise and then solve them for the document that describes the > mechanism that is the root of the problem. > > > > Gyan2> You have hit right on the interoperability issue where you > have brought up that it?s a design matter to use SAFI 4 IPv4 LU and > have the choice to use SAFI 1 IPv4 Unicast. So that is the crux of > 4PE that the > IPv4 prefixes must be labeled. That?s a main reason for > standardization that the IPV4 LU must be used. > > > > The second thing is about wording/writing. I don't want to seem rude > or something but it was challenging for me to read the document. I > believe it should be rewritten in a clearer way. > > > > Gyan> No worries, I can work with the authors to clean up the writing > Gyan> and > thank you for the feedback. > > [IM] Thanks! > > > > Talking about the 4PE and after reading this document I disagree with > the idea to use LU as the only way to spread reachability (actually I > prefer almost not to use it for this task it better suits LSP signaling). > > > > Gyan> The reason for the BGP LU label binding of all the IPV4 > Gyan> prefixes > tunneled over the core is for the PHP node exposing the native IPv4 > packet which would not have the EXP marking PHB scheduling. > > [IM] This is possible without the distribution of IPv4 routes with labels. > I can distribute just a single route toward their next hop which is > the best thing BGP-LU does. The label stack would have two labels. > > > > Gyan2> I am not following. BGP LU allocates and advertises all the > prefixes with labels. When you distribute a single route as SAFI 1 it > does not have a label but if you distribute a SAFI 4 route it does > have a label and is LU. > > > > This is exactly what is done in 6PE as it as well uses BGP-LU for the > same reason labeling all the IPv6 prefixes tunneled. This is a good > example and reason for standardization. > > [IM] 6PE can be done without labeled unicast at all if talk about the > interconnection of IPv6 islands over IPv4 core. That's why I said -- > this is a design matter. > > > > Gyan2> I don?t see how that?s possible without breaking QOS EXP PHB > scheduling on the PHP egress PE. You argument is the reason for > standardization. If we go down the path you are describing that this > is a ?design thing? and implement however you like we would have all > sorts of interoperability issues. > > > > If one vendor labeled the tunneled prefixes and another vendor > implementation did not we would run into issues. > > [IM] And this is a good thing (I mean having several ways to make > things done). You should require your vendor to support both options > or don't buy gear from a vendor who can't do it. > > > > Gyan2> As I said your argument for keeping things open and a ?design > thing? is a reason for standardization as was done with 6PE and you > can see all vendors have implemented exactly that using IPv6 LU and > not IPv6 Unicast to connect IPv6 islands over an IPv4 core. > > > > We have not had at least in North America and Europe many networks > that have migrated to IPv6 core so have not seen interoperability > issues however as more operators now start to migrate to an IPV6 data > plane ..MPLS, SR-MPLS, SRV6 we could have issues so I think it?s > important to get this standardized. > > [IM] Yes we ran over lots of such issues too but all of them were > pieces of some concrete technology. > > > > This approach governs me to always bind any reachability to a PE but > not to a CE. > > > > Gyan> Yes for an important reason for the PHP node POP and forwarding > native IPv4 packet and breaking EXP scheduling on the last hop to the > egress PE > > [IM] As I pointed out previously there is no difference if we don't > distribute reachability without labels and if we use BGP tunnels to NH > over underlay tunnels (RSVP, LDP, whatever). > > > > How can I implement EPE this way? > > > > Gyan> You can still implement EPE with BGP-LU SR EPE or EPE w/o SR > > [IM] Could you please describe the case without SR? > > > > Gyan2> With EPE the ingress PE signals the egress next hop and > which hop to be used via centralized controller PCE / BGP-LS and can > be done using RSVP-TE or SR for EPE > > > > Juniper example > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopic > s%2Ftopic-map%2Fbgp-egress-traffic-engineering.html&data=05%7C01%7 > Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8 > ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C3000%7C%7C%7C&sdata=CVUJKUZW7%2FVZiGAvp1LhY6MEhn%2FeRgK0 > %2Fl%2FzCc%2FS4dc%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .juniper.net%2Fdocumentation%2Fus%2Fen%2Fsoftware%2Fjunos%2Fbgp%2Ftopi > cs%2Ftopic-map%2Fbgp-egress-traffic-engineering.html&data=05%7C01% > 7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee > 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7C&sdata=CVUJKUZW7%2FVZiGAvp1LhY6MEhn%2FeRgK > 0%2Fl%2FzCc%2FS4dc%3D&reserved=0> > > > > > > What if I want to advertise IPv4 prefixes with vanilla IPv4 (1/1) with > IPv4-encoded NH (let's say with the CE address) and propagate this NH > as > IPv4 LU with the IPv6 NH? > > > > Sure that would work fine. That is exactly what is stated in the > draft as the process for 4PE. > > [IM] Your document requires me to use BGP-LU for IPv4 reachability > dissemination, I don't see why I need to resolve an IPv4 LU route over > another IPv4 LU. > > > > Gyan> I think you are getting 6PE and 4PE mixed up. With 6PE you > have a IPv4 transport LSP tunnel IPv4 next hop and IPv6 prefixes > distributed as labeled within the tunnel. With 4PE you have a IPv6 > transport LSP tunnel > IPv6 next hop and IP4 prefixes distributed as labeled within the tunnel. > > > > I see a lot of "MUST" preventing me from doing so. > > > > Where ? Please quote the line or paragraph > > [IM] Let's dig into the third section. > > 1. *Exchange IPv4 reachability information* among 4PE Ingress and > Egress PE routers using MP- BGP [RFC2545 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .ietf.org%2Farchive%2Fid%2Fdraft-mishra-idr-v4-islands-v6-core-4pe-02. > html%23RFC2545&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2 > ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 > C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5Wb > LXtohc3M868Yytz6vBIsKchpdCzGJcQNXkextMOQ%3D&reserved=0> > ]: > > In doing so, the 4PE routers convey *their IPv6 address* as the BGP > Next Hop for the advertised IPv4 prefixes. > > [IM] What if I don't have any IPv6 addresses on PE-CE interfaces and I > don't want to use the loopback IPv6 address? > > > > Gyan2> The PE-CE interface in this 4PE use case is IPv4 islands > over an IPv6 core so the Island CEs are IPv4 attached PE-CE. So here > we are conveying the IPv6 address which is the ingress and egress PE > loopback to build the transport IPv6 LSP to advertise the IPv4 LU > prefixes being tunneled. > > The Subsequence Address Family Identifier (SAFI) used in MP-BGP *MUST > be the "label" SAFI (value 4)* as defined in [RFC8277 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .ietf.org%2Farchive%2Fid%2Fdraft-mishra-idr-v4-islands-v6-core-4pe-02.html%23RFC8277&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=L0cT0h4kJ3qOP9eV%2BA%2FwsZ%2BliqWIV7UHsFj3Ua5Y%2Bnk%3D&reserved=0>] called BGP Labeled Unicast (BGP-LU). > > [IM] Why can't it be SAFI 1? Why MUST I always use SAFI 4? I don't want. > (Again, I still can have two labels in the stack). > > > > Gyan2> How would you have 2 labels in the label stack if you use > SAFI 1 > 1/1 IPv4 Unicast as that would be ?native IPv4 packets? non labeled no > MPLS shim. So as I said before and the reason for the standardization > is that if you don?t label the IPv4 prefixes from the IPv4 island > being tunneled over the IPv6 LSP then on the PHP node when the > transport label is popped implicit null value 3, the native IPv4 > packet is exposed and is forwarded from the egress P PHP node w/ PHB > scheduling broken as EXP match cannot occur without the IPv4 prefixes > being labeled IPv4 LU. That is a requirement for 4PE to work w/o > breaking QOS EXP scheduling and is the procedure that must be followed for any 4PE implementations. > > > > So It?s not just breaking QOS EXP scheduling as once the PHP POP > happens on the PHP node for 6PE the native IPv6 packet is exposed and > that cannot be forwarded as the core is a per standard design > following RFC 5545 Softwire mesh framework a single protocol IPv4 only > core so the IPv6 packet is dropped and cannot be forwarded. > > > > As well for 4PE It?s not just breaking QOS EXP scheduling as once the > PHP POP happens on the PHP node the show stopper deal breakers is > that the native IPv4 packet is exposed and that cannot be forwarded > as the core is a per standard design following RFC 5545 Softwire mesh > framework a single protocol IPv6 only core so the then the IPV4 packet > is dropped and cannot be forwarded. > > > > As well is discussed in the draft even if IPv6 explicit null is used > Pipe mode RFC 3270 MPLS Diffserv, explicit null label cannot carry a > native IPv4 packet SAFI 1 and would be dropped and would have to be LU > labeled IPv4 packets or the packets would get dropped. In a global > table routing scenario IPv4 packets tunneled over an IPv4 core don?t > have to be labeled as it will break QOS EXP on the PHP node but in > this case the native IPv4 packet is exposed and can still be forwarded > and not dropped as all the core P nodes are IPv4 enabled core, as with > the 6PE encapsulation mismatch and resulting IPv6 packets being > dropped. Similarly In a global table routing scenario IPv6 packets > tunneled over an IPv6 core don?t have to be labeled as it will break > QOS EXP on the PHP node but in this case the native IPv6 packet is > exposed and can still be forwarded and not dropped as all the P nodes > are IPv6 enabled core, as with the 4PE encapsulation mismatch and resulting IPv4 packets being dropped. The ?design thing? > scenario does come into play here with what I described above where > the CE packet protocol matches the core protocol then you have the > option to label or not label the packets. Some vendors have the > ability to match on both dscp and exp so even when the PHP POP and > forward happens on the PHP node the router can schedule based on DSCP > and if the label is present switch gears and schedule match on EXP. > So based on what is supported in the protocol matching scenario can > decide to label or not label the customer traffic ingressing the core. > > > > ***I hope what I said above really helps clarify and cleans up any > confusion and I can as well make these points more clear in the > draft*** > > > > So to reiterate the show stopper and why the packets being tunneled > over the core must be labeled must have the MPLS shim for label > switching and forwarding is the protocol mismatch scenario that > happens when the native packet gets exposed after the PHP POP and the > P / PE all core nodes are > IPv6 only - IPv6 only core for 4PE scenario and IPv4 only - IPV4 only > core for 6PE scenario. > > > > > > That's why I said that we don't have to have the exact way to do > things. I agree that is good to describe the necessity of having two > labels and why but I don't think that it's the standard matter how I > reach this goal, which family I will use, and so on. > > > > Gyan2> As I said your argument for SAFI 1 is the main reason why we > Gyan2> need > to have 4PE procedure to use SAFI 4 IPv4 labeled unicast so that all > implementations of 4PE must follow the standard specification for > interoperability. > > > > > > > > Thank you > > > > > > ??, 12 ????. 2022 ?. ? 02:08, Gyan Mishra <hayabusagsm@gmail.com>: > > > > Thanks Robert for your feedback on the draft. > > > > Dear IDR > > > > Please review the draft and provide feedback. > > > > Thank you > > > > Gyan > > > > On Fri, Nov 11, 2022 at 6:46 PM Robert Raszuk <robert@raszuk.net> wrote: > > Gyan, > > > > Returning today from London I did read the draft. It's a great example > of how IETF documents should *NOT* be written. 47 references says it > all. You are mixing pieces from completely different areas all in one place. > > > > Indeed I encourage everyone to read this draft and submit an opinion > to the list before WG takes any action on it. > > > > > You mean IPv6 mapped IPv4 address. > > > > No, I meant what I wrote. > > > > Kind regards, > > R. > > > > > > On Sat, Nov 12, 2022 at 12:13 AM Gyan Mishra <hayabusagsm@gmail.com> > wrote: > > Robert > > > > On Fri, Nov 11, 2022 at 4:49 PM Robert Raszuk <robert@raszuk.net> wrote: > > Gyan, > > > > RFC8950 is all that is required to be standardized in IDR for > connecting > ipv4 sites over ipv6 core from the perspective of BGP extension to > propagate reachability in the control plane. /* Btw as stated in my > previous note even that is not needed if we would solve the > requirement using v4 mapped v6 addresses. */ > > > > Gyan> 4PE as well as 6PE is more then just reachability extension > next hop encoding. Please read the draft and then provide me some > feedback as it goes over all different inter-as scenarios as well as > details requirements for 2 level label stack related BGP-LU labeled > unicast labeling binding of all the IPv4 prefixes. As well as > implicit null PHP and explicit null case for RFC 3270 pipe mode support etc. > > > > You mean IPv6 mapped IPv4 address. That has always been very > confusing for troubleshooting as the next hop should follow the core > protocol used for reachability and not the NLRI which would have been > done backwards with > IPv6 mapped IPv4 address and who knows what that would encode you look > like.. for IPv4 core IPv6 NLRI over and IPv4 next hop is IPv4 mapped > IPv6 address ::FFFF:10.0.0.1. That was one of the main reasons for > encoding simplicity to change to IPv6 address follows the core > protocol in RFC 8950 and not use IPv6 mapped IPv4 address. Since the > mapped address is not a legitimate address extra coding hooks need to > be done to make it routable based on the embedded PE loopback in the > next hop address. All avoided and confusion avoided by using RFC 8950 > style next hop encoding and not using a mapped address. > > > > > This draft also defines critical extensibility to segment routing > SR-MPLS and SRv6 which did > > > not exist when 6PE RFC 4798 was developed. > > > > IDR does not standardize SR-MPLS nor SRv6. > > > > Gyan> I am not standardizing SR as here just providing > extensibility of the specification to support Segment Routing. > > > > > RFC 8950 as stated defines only the next hop encoding and for > > example > does not define > > > BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification nor does it > > define > BGP LU > > > RFC 8277 specification AFI /SAFI 2/4?. > > > > This is all defined in stated above documents. > > > > Gyan> My point here is that AFI/SAFI 2/128 and 2/4 use RFC 8950 > which only defines the next hop encoding for the AFI/SAFI and not the > specification for the AFI/SAFI and thus the RFC. RFC 4798 6PE uses > IPv4 mapped IPv6 next hop encoding which does not have a next hop > encoding specification but still does have an RFC for 6PE. Even if a > next hop encoding standard existed, that would just be for the next > hop encoding, does not mean that a standard for 6PE is not necessary > for interoperability as is the case here. > > > > IDR drafts focus on required protocol extensions to BGP. I do not see > any new protocol extensions in this draft anyway. > > > > Gyan> 6PE RFC 4798 as well does not have a IANA code point allocation > Gyan> for > a protocol extension, however it does define a procedure and process > of how 6PE works which is why it was still standardized so ensure > interoperability between vendor implementations. There are many more > examples as such that have > > > > Regards, > > R. > > > > > > On Fri, Nov 11, 2022 at 10:38 PM Gyan Mishra <hayabusagsm@gmail.com> > wrote: > > > > Robert > > > > RFC 8950 only defines only the IPv4 NLRI over IPv6 next hop encoding > IANA BGP capability code point 5 that updates RFC 5549 next hop > encoding for SAFI 128 and 129 where the 8 byte RD set to 0 was left of > the next hop encoding specification. > > > > RFC 8950 as stated defines only the next hop encoding and for example > does not define BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification nor > does it define BGP LU RFC 8277 specification AFI /SAFI 2/4?. > > > > The next hop encoding is just component of the overall 4PE > specification which did exist till this draft was published. There > are vendors that have implemented 4PE which may or may not even be > called 4PE, and this draft defines the name ?4PE? and what it means > form a specification perspective and thus would ensure the > standardization of all implementations to ensure interoperability. > > > > As operators start migrating their core to IPv6 this does become a big > deal as most operators have multi vendor environments and so this > comes to the surface as a hot topic to ensure interoperability. > > > > This draft also defines critical extensibility to segment routing > SR-MPLS and SRv6 which did not exist when 6PE RFC 4798 was developed. > > > > Many Thanks > > > > Gyan > > > > On Fri, Nov 11, 2022 at 3:56 PM Robert Raszuk <robert@raszuk.net> wrote: > > Gyan, > > > > IDR draft: > > > > The 4PE draft connecting IPv4 islands over an IPv6 core over the > global table is similar in semantics to 6PE RFC 4798 which connects > IPv6 islands over an IPv4 core over the global table and the draft is > extensible to SR-MPLS and SRv6. There currently is not a standard for > 4PE so this draft would standardize 4PE for vendor interoperability. > > > > Not true. > > > > Quote from RFC8950: > > > > *Error! Filename not specified.* > > > > I do not see anything your draft would add to it. > > > > Cheers, > > R. > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-mishra-idr-v4-islands-v6-core-4pe%2F&am > p;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08da > c76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6380415592835380 > 75%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bQjpEyK1tD%2Fo%2FtyF > dlcpjSfk9QLtxzj64yGnK482s90%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-mishra-idr-v4-islands-v6-core-4pe%2F&a > mp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08d > ac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538 > 075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bQjpEyK1tD%2Fo%2Fty > FdlcpjSfk9QLtxzj64yGnK482s90%3D&reserved=0> > > > > BESS drafts - these drafts are completely different from IDR 4PE draft. > > > > I have already combined two of the drafts into one for the IPv4-Only > PE All SAFI draft > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv4-only-pe-design-all-saf > i%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd > 64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559 > 283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pNZAEjP01JBHU > N2hwM2En9lC6SgS3lu3dZ0TgofDLBU%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv4-only-pe-design-all-sa > fi%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6b > d64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155 > 9283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pNZAEjP01JBH > UN2hwM2En9lC6SgS3lu3dZ0TgofDLBU%3D&reserved=0> > > > > IPv6 Only PE Design BCP draft below was adopted last year and the new > draft extensible to ALL SAFI Standards Track below I plan to progress > separately. As one is BCP and the other Standards track I don?t think > they could be combined and even if they were combined into the super > set all SAFI that would have to go through adoption process again > anyway so I plan to keep separate. > > > > This draft I will queue up for adoption call. > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv6-only-pe-design-all-saf > i%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd > 64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559 > 283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u%2BOch3g0O5Y > 7PaDdfdMZC3vpNVOLLLr9qBZg2Y3%2Begw%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-ipv6-only-pe-design-all-sa > fi%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6b > d64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155 > 9283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u%2BOch3g0O5 > Y7PaDdfdMZC3vpNVOLLLr9qBZg2Y3%2Begw%3D&reserved=0> > > > > > > Many Thanks > > > > Gyan > > > > On Fri, Nov 11, 2022 at 6:19 AM Ketan Talaulikar > <ketant.ietf@gmail.com> > wrote: > > Hi Gyan, > > > > Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 > in > IDR) as we lost time due to the audio issues: > > > > (1) put the portions to be standardized (very focussed/small > hopefully) in one single draft and post/share with both IDR and BESS > since you are changing NH encoding (from what I heard?) > > (2) all other informational/BCP material could be combined in a single > draft (perhaps the existing BESS WG draft) > > > > -- <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SVRW965bh77zdBEhduhMP01GfKzF8YL9bkp3HrSLoxE%3D&reserved=0> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347* -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fidr%2Fattachments%2F20221115%2Ffa6aaf4f%2Fattachment.htm&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=irJ1ZEUGr3Km2k9U5I6uMF1xJiO%2B7o7gbgoMNA8T%2Bdk%3D&reserved=0> ------------------------------ Subject: Digest Footer _______________________________________________ Idr mailing list Idr@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X5X%2BsFuBLMcCJ1Tn44XpzP%2BfbCKFNTxH%2BjK7o9NRIFU%3D&reserved=0 ------------------------------ End of Idr Digest, Vol 223, Issue 46 ************************************
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Robert Raszuk
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Ketan Talaulikar
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Robert Raszuk
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Robert Raszuk
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Igor Malyushkin
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Igor Malyushkin
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Robert Raszuk
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Nick Hilliard
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Igor Malyushkin
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Igor Malyushkin
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Igor Malyushkin
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… tom petch
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Robert Raszuk
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Linda Dunbar
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Huaimo Chen
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Linda Dunbar
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Gyan Mishra
- Re: [Idr] [bess] Suggestion on v4-only/v6-only dr… Haoyu Song