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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64
> d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155928
> 3381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=OrO9M2UBYo%2B8o
> rqdBTVUZnM9JJUaybApZafQ97DFGHE%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd6
> 4d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6380415592
> 83381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=OrO9M2UBYo%2B8
> orqdBTVUZnM9JJUaybApZafQ97DFGHE%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futu
> rewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1
> d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&amp;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&amp;data=05%7C01%7Chaoyu.song%40fut
> urewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&amp;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&amp;data=05%7C01%7Chaoyu.son
> g%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b2401
> 89c753a1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000%7C%7C%7C&amp;sdata=RanZPiXso2cT8gP%2BdZ9gpuJFf%2B8r616vfdobQRpIIN
> 8%3D&amp;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&amp;data=05%7C01%7Chaoyu.so
> ng%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C0%7C638041559283381860%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&amp;sdata=RanZPiXso2cT8gP%2BdZ9gpuJFf%2B8r616vfdobQRpII
> N8%3D&amp;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&amp;sdata=JeSYnNhr%2BdO8TJNhB
> AyR2pRT1aqyUiOaIl%2FHpLYvq7g%3D&amp;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&amp;sdata=JeSYnNhr%2BdO8TJNh
> BAyR2pRT1aqyUiOaIl%2FHpLYvq7g%3D&amp;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&amp;data=0
> 5%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64
> %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=iQ4qdwwu9EZVw2PQ8E%2BpRNRECT
> l1dFXEUKzJUJAO3P4%3D&amp;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&amp;data=
> 05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea6
> 4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=iQ4qdwwu9EZVw2PQ8E%2BpRNREC
> Tl1dFXEUKzJUJAO3P4%3D&amp;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&amp;data=05%7C01%7
> Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8
> ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=CVUJKUZW7%2FVZiGAvp1LhY6MEhn%2FeRgK0
> %2Fl%2FzCc%2FS4dc%3D&amp;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&amp;data=05%7C01%
> 7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee
> 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=CVUJKUZW7%2FVZiGAvp1LhY6MEhn%2FeRgK
> 0%2Fl%2FzCc%2FS4dc%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2
> ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5Wb
> LXtohc3M868Yytz6vBIsKchpdCzGJcQNXkextMOQ%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=L0cT0h4kJ3qOP9eV%2BA%2FwsZ%2BliqWIV7UHsFj3Ua5Y%2Bnk%3D&amp;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&amp;sdata=bQjpEyK1tD%2Fo%2FtyF
> dlcpjSfk9QLtxzj64yGnK482s90%3D&amp;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&amp;sdata=bQjpEyK1tD%2Fo%2Fty
> FdlcpjSfk9QLtxzj64yGnK482s90%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd
> 64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559
> 283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=pNZAEjP01JBHU
> N2hwM2En9lC6SgS3lu3dZ0TgofDLBU%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6b
> d64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155
> 9283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=pNZAEjP01JBH
> UN2hwM2En9lC6SgS3lu3dZ0TgofDLBU%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd
> 64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559
> 283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=u%2BOch3g0O5Y
> 7PaDdfdMZC3vpNVOLLLr9qBZg2Y3%2Begw%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6b
> d64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63804155
> 9283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=u%2BOch3g0O5
> Y7PaDdfdMZC3vpNVOLLLr9qBZg2Y3%2Begw%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=SVRW965bh77zdBEhduhMP01GfKzF8YL9bkp3HrSLoxE%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=irJ1ZEUGr3Km2k9U5I6uMF1xJiO%2B7o7gbgoMNA8T%2Bdk%3D&amp;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&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C277f5a2ffeea4c6bd64d08dac76aea64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638041559283538075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=X5X%2BsFuBLMcCJ1Tn44XpzP%2BfbCKFNTxH%2BjK7o9NRIFU%3D&amp;reserved=0


------------------------------

End of Idr Digest, Vol 223, Issue 46
************************************