Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08

Antoni Przygienda <prz@juniper.net> Mon, 12 December 2022 17:07 UTC

Return-Path: <prz@juniper.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E60C14CEE1; Mon, 12 Dec 2022 09:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 (2048-bit key) header.d=juniper.net header.b=TMdyZKJv; dkim=pass (1024-bit key) header.d=juniper.net header.b=CzP5gGOs
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 7T5T76osW-6P; Mon, 12 Dec 2022 09:07:10 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 59AFEC14F6EB; Mon, 12 Dec 2022 09:07:10 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BCGbUH9012661; Mon, 12 Dec 2022 09:07:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=40peo9oAMHvejkj4NA7DCcAKa1jKP02mnWSICD1VUh0=; b=TMdyZKJv2G0gJKjNdVFQPgp6X1gokdZwUYeMvFP2wpEpysP4GwCPsNkbQ6FecwSSxrzU DS6qr4ih/K42fOKlThQbpPaMPO8NM9U54aeMu0MxJxgx0/2060hc66otBRQiEIDsnq7f 4Dpb+tEf5hv++87f1rJlOgR6MabxOjr+uvwOLKUql3BxlLwUoF6BX4DJx2gaPavool5E LTOysZ71VYK4VHELl7UePvi6FUsBd/Uxlwi7byZpfpb036Ua59ZdUhTRwOly4/TA6Cuy wrVEAKFBdb0lNMIqywzOZSuMnMxfdoeMx8fIUrHSG0Zain3Tqsf8tW9ldSslt5W/4N6H fg==
Received: from co1pr02cu001-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17011010.outbound.protection.outlook.com [40.93.10.10]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3me3mu0kkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Dec 2022 09:07:09 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E0BlGcFoLrIXBZPMMTBmpLpHTrA0xg5hfrsKxY+DIJfYwlIf9dFyyjnffVwvTy7uwZPRxkKpVcoYkw2B0a6udZEE7nwKPpuWIT4PtzjxsufRBiCkBmvgxIHP77G3UJJjHNfEz4HwuTUCKkE/wP+IWVZ5mdV55K+oUow5vi44WeStLsMEJ9GuQbzonHn0EsSVerMbHmDQ5jh2maNAA55HzIu1ocIXIghauFgPNrvkAoNNt9A62CVLY2a1fsxB+WRgZDlpzsGhoS8NR2dnuy+g+kK+ZC4pmHCI4ZL7ShASCOaLGuT+k0qzQFIZsblfHObkVJJdfe+5t+UQYKcb48YAfA==
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=40peo9oAMHvejkj4NA7DCcAKa1jKP02mnWSICD1VUh0=; b=azbE/fCXPShpiAWtuoK46EgFvBkqPw/GWDu0UaU1J7ygNKdUTWBfDXUgMDrhleGTxoX1NZ/8FwPssX1Jm29DNjwN46/YHf1OfAq7mpsK5CbbOIqtdmjHdq/zpcuk9TfABPkHWAKJDcu3N7DxtDVog2eFoav6sCmpOTXagFDUbXvCb0TjRpcMKxbHqmxC5wDUPSAg9X8X/DNJ6Obk2lJ4QHNUPbrZyfLFU76l7/xIRZHGbcBiBEyaMWIbCx1fC2WmMjcam4D9nd+JD6Pkc8thQPtrW20HP7v3px4p3q5NmwVXTnpQ9cai4aH3moWSPNqD9kz3g4uL4za2ZhCFAqgTTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=40peo9oAMHvejkj4NA7DCcAKa1jKP02mnWSICD1VUh0=; b=CzP5gGOskEUoSpPYNEqc+Mfkx2P0s224lRwXqRffbhdVSrpieVK6Zeq/zAyMZ/Utd4U489+BBVvo5elWJalzoRzXSv0Ur9uq1YE6i0P1dEei4Mmt0k3p9cejsXG2eQIcXeAYC0mGkuXtuPtvF+PyYqAD0lLx2fV6bq33FrnXreY=
Received: from CO1PR05MB8492.namprd05.prod.outlook.com (2603:10b6:303:eb::7) by BLAPR05MB7316.namprd05.prod.outlook.com (2603:10b6:208:293::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.13; Mon, 12 Dec 2022 17:07:06 +0000
Received: from CO1PR05MB8492.namprd05.prod.outlook.com ([fe80::1844:d3e5:f627:8862]) by CO1PR05MB8492.namprd05.prod.outlook.com ([fe80::1844:d3e5:f627:8862%9]) with mapi id 15.20.5880.019; Mon, 12 Dec 2022 17:07:06 +0000
From: Antoni Przygienda <prz@juniper.net>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-mvpn-evpn-aggregation-label.all@ietf.org" <draft-ietf-bess-mvpn-evpn-aggregation-label.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08
Thread-Index: AQHY7izCxW7ZaM2bcEesoh+C8NHUOK5qtiNAgAAFyP0=
Date: Mon, 12 Dec 2022 17:07:06 +0000
Message-ID: <CO1PR05MB8492947B8825778107726C8FACE29@CO1PR05MB8492.namprd05.prod.outlook.com>
References: <166733289444.30158.1956328356800507664@ietfa.amsl.com> <BL0PR05MB5652EDA7360CAC8930BD26C9D4E29@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652EDA7360CAC8930BD26C9D4E29@BL0PR05MB5652.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-12-12T16:50:08.0000000Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR05MB8492:EE_|BLAPR05MB7316:EE_
x-ms-office365-filtering-correlation-id: 832aad15-7300-40b0-c702-08dadc634c50
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rCyoBsS2dRi4nmcBpIHrskUwRltN7H5V/RRym3Zo8P6R3q0AjJWmXeWp9/e9Tu0JOwyubKwoU3rnwLh+S0MX8MXNZcatP6JVfNiWti3BMBYlGwDf/0wCvPdHlDblB82SGC3DsZeFYMchMJdDE6i3sWSjylDYoR7BtnP0+L2E0Ld7M/jVl/zfCAONLq7ts2rpkwQpp3PylxkFzsSJaJ7NzRF2EldSMt5scE5FXoozJrZ8yKuActQ0raVsntu+zPkOhdlusq5QId3Vm7mXvy21j7U0gpBKUOHCApNHg9bpnySyLFnFu/u1GRK4QwNsPjkHE4wok4X3MfSjsjtdWRWtJG/a3RG6t5JHwWTEn0N2butYRYW5XWddiQZ2njcdUU5ada2OsLiXhezDCTJUYwljVhZEI1HA2dQccUwEjPEgDAotA/wFEhH9r3SWIgptZFmS7M4Kme8SJIqMNiH4POxveWyoJyVZT6Y3/gh5MyxD510iYHpRSNmR2lhB9hk98a6z9EKGma4U7CKb1Pw7waNDRBV1Z8lq22CmBCozwkEPfAlUGpWz0VzR0Xiea+ePU9TfBNKWweu89JC1ezlX8ElWG54SVG1p8EoNjFGy1a2CedbCRgvSrvZ5lOiOFCGRF0WMsuKzJ2ZwII7GSFoT8k54G27DEP2JfQOMIrxfDYB1jsX5Qfasw+yYcjkeWGu3v0AzJ5q2bbZZA7d0yY+c59iEetmExYk5v1gUEuC9PFTTY18=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR05MB8492.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(451199015)(38070700005)(166002)(38100700002)(122000001)(33656002)(86362001)(110136005)(8676002)(450100002)(91956017)(76116006)(316002)(4326008)(66946007)(71200400001)(478600001)(52536014)(5660300002)(66556008)(64756008)(66446008)(2906002)(8936002)(30864003)(66476007)(41300700001)(55016003)(83380400001)(966005)(6506007)(26005)(9686003)(54906003)(186003)(53546011)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: KbQCLofBcBcxCEMx9WHygGjbXxDWp5XzBIHH0edIQ/xat+N24s09CLb4wbcSImNN+WrPNZ3ows4AGHSwdJ9bnF71qmGr73N4b9Czr/TWni9oP5YrayqzF/uxThxiXRKJIvmWoH0kqyJwrbenBBRTXrTy4/BTFdKTgJ/EDrqXTQSA9sOcURtfUcAMYv0OmowbUISDlDXMkTWYQ14W6gQHCWdxSlpqKPrS65wIUgyKA7938QfbKqLQRbiHTc5GGJJ7O6CJPRifkdvL4FSyTfAGrStiGLKVBE11vrBMWAtXnW+/zhaSPWmkM8MFOmaLE0nKt43Pjk4vWBnBdkYlE5tfZzEoJeAqEC6bnBjbw3tywbd/7nzDWpZel6QU7X8WswB7Vxup94JwkobOmcu4ehMCKj3dL/qJ99GIHZDaNfpX0/skESVlgq45jUa1N062fG8g0lDrgUke+V1C1rKXG4VaS6jiPKAZkwtXas0Otq55TxhZY7srQL+BceD45e4z3n7o/JD15Fg5DdDc0R13vDfdcXHSOTP3uo3CHUMbM4hryIEQt5ZL+5Uz4RTqmUGBPr8CC7COfETi6Hnq9y8lmscCaYg3hXXBiGi+CYCthQbIUbVOJ3MzdUbixWZ4alD60wyRm6sK4+VbNqBCZal2xvmywtEV00UFCcjXeOvBU3zdYR3oGH9q/7CPUEX4bkixHDfxoY227TayXRewh/nhkidOqixGnFvcOrtGGku7vOeTPOq2kg0U0iFmaQb5zoZ1wtvMi4INn1c2QzI9o5pBSTgMSCIVb29e7kzprhh4aaTDrZByx2c5Luu8IshS8woJ911a/n+2V+76c9meEkr6ZL+uEOSv6pBSMSekBTBM7ar+SfFMuxuAq8t+z6IIBXJkFSFr+29TIMb6e/D18kUK/s91NGxeJbdjFxax37rLIBVu4+Qjhf1LAbrU3mJEj0E6fvnvBYQYlAdkA1Kd4Dprss4/69dyjxwA/tmyjluhso7XriaAuOny/L8QCtIwqcSk9ZbsgcVtEzG5mE1nhocw/ZM654jFXuvCvH9S6EDWECP1iuI6VCZL7Fu3COu/jugw/7Ob43vS+Fe2HrRL4mwzncKMqlT8T5UY6KRN+8x99xyXu+5EXqE2VypaKreOJfQYu/7irlOeMsHo01kMUhYbekSrWxaSLCCauHT30SqVRSLdp9TUl+tp/MBGFEoe3deeE1uYzXcT/Z7/TqQQeF3lQqFH4snNGg7Q9fmeIiP3tMbIS7G6b/P87+IfZO1vw7nnjU3aNnBENjIqicgKTI9/34PROs4wmVziBy6uV4K5fiGVYRfhopieCJwaCKw511MgbTpfyJJzZnxBqd4q3H5gYQA+x1bdPLS8kSlvCxpJ7ahf8iPDf0xNKttCmR0zy5BK2+u1uvIa72eGsKbqKQgPiRPYqrM7IeuyPgQxW/eHpPFSbAvyKfmkX+orUC3LLkM1+DaTzDdYEaw3YJ7eXqtxN6FcytbwTrYhOjRFV3zK0ZCUINm9eqm/6BUjn6HFac8XDakWpqwHXzvFKIRZUwF/TwhXKZcqftY6/JSSGelnJMc5BeUcRsdax84IuLjPJ+5aM8wK
Content-Type: multipart/alternative; boundary="_000_CO1PR05MB8492947B8825778107726C8FACE29CO1PR05MB8492namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8492.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 832aad15-7300-40b0-c702-08dadc634c50
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2022 17:07:06.6113 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: z3Ijy3dzZaFcTwK7LI90wt/djfDtzso7jCOOklcb3F8jnBh0go33QOE+nR8wLNXD
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7316
X-Proofpoint-GUID: sElluvtjtB5xVVzxZdmPD3kmFvkT0voZ
X-Proofpoint-ORIG-GUID: sElluvtjtB5xVVzxZdmPD3kmFvkT0voZ
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-12_02,2022-12-12_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 priorityscore=1501 adultscore=0 clxscore=1011 impostorscore=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212120154
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Tnc2FLZhr9zle2VLyonV27xcFQU>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 17:07:15 -0000

Thanks. All adressed AFAIS


  *   Tony

From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Date: Monday, 12 December 2022 at 17:50
To: Antoni Przygienda <prz@juniper.net>, rtg-dir@ietf.org <rtg-dir@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-mvpn-evpn-aggregation-label.all@ietf.org <draft-ietf-bess-mvpn-evpn-aggregation-label.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>
Subject: RE: Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08
Hi Tony,

Thanks for your thorough review and comments. I have posted the -09 version that I believe/hope have address your comments/concerns.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-09

Please see zzh> below for some details.


Juniper Business Use Only

-----Original Message-----
From: Tony Przygienda via Datatracker <noreply@ietf.org>
Sent: Tuesday, November 1, 2022 4:02 PM
To: rtg-dir@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label.all@ietf.org; last-call@ietf.org
Subject: Rtgdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-08

[External Email. Be cautious of content]


Reviewer: Tony Przygienda
Review result: Has Issues

As first, technically sound except point 18. Rest of the commentes provided are all for easier readability/clarity for a reader that may not be super instrinsically familiar with the world of overlay multicast tunnels underlying VPN technologies first. I am quite versant in it but even then, the complexity of the field made me stumble on some assertions given without explanation.
Then, good amount of omitted words etc necessary to read as coherent English sentences. Ultimately, some of the transitions in terms of causality chains do not connect and can leave the reader stranded which I'm pointing out in specific comments.

Numbered:

1.  document only distincts between p2mp and mp2mp rather than using the PMSI terminology with inclusisve/selective [RFC6513]. the S/I is not relevant but it would help readability if that would be explained. Especially since the S/I starts to be introduced in 2.2.2.1 suddenly.

Zzh> The difference between P2MP and MP2MP is actually not important and not the focus of the document. The document starts with P2MP because it is more common; it does talk about MP2MP's applicability with some specifics afterwards.

Zzh> Use of per-VPN/BD/ES DCB labels does not work for tunnel segmentation, and entire section 2.2.2 is about how we mitigate that. Section 2.2.2.1 explains the need for per-PMSI labels using selective tunnels example, and section 2.2.2.2 extends it to inclusive tunnels.
Zzh> For an average reader, selective/inclusive tunnels are easier to understand than S/I-PMSI terms so the sections are based on "tunnels" instead of PMSIs, but now I have added additional glossaries and text to tie the two together.

2. Terminology
-- provide references for BD/BUM/PMSI/IMET/PTA in terms of RFCs defining them properly. Currently the section is just acronym expansion really.
-- provide definition of "aggregate tunnel" in the terminology section rather than later in the document for consistency
-- add definitons for "context space", "upstream assigned label" and "ESI Label" here as well rather than later in the document. This may lead to more conscise and readable introduction section
-- add definition for DCB
-- add def for SRGB with according SRGB

--- I suggest to add upstream assigned (and downstream) labels to definitions as well since it's so central to the document. Acronym expansion + RFC ref is fine AFAIS but at least the reader can peddle back and know in one shot where all the stuff comes from or read things upfront to have an inkling. The drip-drip technique uesed in the document is ok'ish since it makes an illusion of gradual introduction into the solution space on first read but makes it hard to find things later, have in one easy shot a quick recall "what was that all about". IME good glossary goes a very long way when attempting a 2nd read or trying to do a fast page-in later.
-- given 2.2.2.1 I suggest to add PMSI + S/I + PTA defintions + IMET + RBR. And maybe minimum definition (or where to find the terminology precisely) for the whole (C-*,C-*) machinery involved in context lookups you pull out in 2.2.2.3

Zzh> I added more terms.
Zzh> I assume most people now just read the electronic copy instead of paper copy, so the drip-drip technique should not only work well for gradual introduction but also not make it hard to find things later? 😊

3. "but each PE would
   know not to allocate labels from that block for other purposes" is difficult
   to read. Rewrite from negative.

Zzh> I removed it entirely. Sometimes less is more 😊

4. "1000 is for VPN 0, 1001 for VPN 1 ...". Write it clearer, maybe "label 1000 maps to VPN 0, 1001 to VPN1 and so forth"

Zzh> Fixed as suggested.

5. "
network.  (Though if tunnel
   segmentation [RFC6514] is used, each segmentation region could have
   its own DCB.  This will be explained in more detail later.)". This separate
   sentence in () is funny, make is a composite sentence or part of previous
   sentence in ()

zzh> I removed it. It's more accurate w/o it.

6. "
However, that is not necessarily as the labels used by PEs
   for the purposes defined in this document will only rise to the top
   of the label stack when traffic arrives the PEs.
"
does not parse as English. this is not necessarily _true_ ? arrives _from_ the PEs (which it always does or you want to emphasize that traffic can "arrive from P" ?) ?

zzh> I hope it becomes clear if I replace "necessarily" with "necessary" - it is a typo 😊

7. "
That way
   they do not have to aside the same DCB used for the purposes in this
   document.
"
Again, not English. "they do not have to _set_ aside" ?

Zzh> Right. Fixed.

8. "if it is difficult". If it is _too_ difficult?

Zzh> Fixed.

9. Here you will loose many readers

"We also augment the signaling so that it is
   possible to indicate that a particular label is from an identified
   context label space that is different than the ingress PE's own
   context label space.
"
If you need to differentiate between a "ingress PE context label space" and another type of context label space you need to introduce this terminology, maybe

"GCLS" for global context label space and "PCLS" or some such thing. Otherwise the reading of the "context label space" depends too much on the context (pun intented ;-)

And then segmentation points seem to have yet another "context label space"
which may need

zzh> I changed all "context label space" to "context-specific label space" to be exactly matching RFC5331 and more importantly changed relevant text to make it clear. Please see the attached diff file.

10. "
Notice that, the VPN/BD/ES-identifying labels from the DCB or from
   those few context label spaces are very similar to VNIs in VXLAN.
   Allocating a label from the DCB or from those a few context label
   spaces and communicating them to all PEs should not be different from
   allocating VNIs, and should be feasible in today's networks since
   controllers are used more and more widely.
"
I would loose the whole thing. It's an analogy across yet another technology and imperfect one on top of that given we have SRC/DST in VXLAN on top and "bias" and all kind of ugly hacks (eeeh, enforced features ;-)

Zzh> Well my impression is that EVPN-VXLAN is used more widely than EVPN-MPLS 😊

11. "
MP2MP tunnels present the same problem that can be solved the same
   way."

What same problem? what same way? Does that relate to vxlan analogy or the same problem as P2MP? So why a section start here?

Zzh> Same problem as in "2.1.  Problem Description" and same solution as in "2.2.  Proposed Solution". A new section is used because of the following additional requirement for MP2MP:
    It is REQUIRED by this document that the PE Distinguisher
    labels allocated by a particular node come from the same label space
    that the node uses to allocate its VPN-identifying labels.
Zzh> I clarified in the text.

12. add to glossary section "PE Distinguisher Labels" with RFC reference

Zzh>  It's a term that is difficult to define concisely in the glossary section. I would still prefer to reference it the first time it is used.

13.
"
though it does not address the original scaling
   issue, because there would be one million labels allocated from those
   a few context label spaces in the original example "
- from those a few context label spaces - does not seem to parse

Zzh> The previous paragraph says:

   In this case, it is not practical to have a central authority assign
   domain-wide unique labels to individual S-PMSI routes.  To address
   this problem, all PEs can be assigned disjoint label blocks in those
   few context label spaces, and each will allocate labels for segmented
   S-PMSI independently from its assigned label block that is different
   from any other PE's.  For example, PE1 allocates from label block
   [101~200], PE2 allocates from label block [201~300], and so on.

Zzh> Basically, instead of each ingress PE upstream-assigns from its own label space, we'll just use one or a few context label spaces and divide that into different label blocks, each block assigned to one PE. Your quoted text "a few context label spaces" refer to those label spaces. The reason to use those a few context label spaces instead of per-PE label spaces is to make it easier for the egress PEs - instead of managing many context label spaces, only a few needs to be managed.

14.
"
to allocate its own label from the label
   block allocated to itself
"
drop the -own- and define what is -label block allocated to itself-. Is that the "segmentation point context label space"?

zzh> I removed the "own". The "label block" is the one described in previous section as the following:

   In this case, it is not practical to have a central authority assign
   domain-wide unique labels to individual S-PMSI routes.  To address
   this problem, all PEs can be assigned disjoint label blocks in those
   few context label spaces, and each will allocate labels for segmented
   S-PMSI independently from its assigned label block that is different
   from any other PE's.  For example, PE1 allocates from label block
   [101~200], PE2 allocates from label block [201~300], and so on.

Zzh> I added a reference to it.

15.
"
[note -
   future revision may extend the applicability of this document to
   Ingress Replication as well]
"

to be expanded or removed

zzh> Removed 😊

16.
" when a segmentation point re-advertise a PMSI "
re-advertise_s_

zzh> Fixed.

17.
"
Note that, when a segmentation point re-advertise a PMSI route to the
   next segment, it does not need to re-advertise a new label unless the
   upstream or downstream segment uses Ingress Replication.
"
I couldn't imagine why. Can you provide a one liner explanation.

Zzh> I can't provide a *one liner* explanation 😊 Here is a longer explanation:
Zzh> The label is used to demultiplex traffic belonging to different PMSIs but carried on the same intra-region tunnel. Because it is allocated from a context label space known to every PE and segmentation points, and the context label space is identified by a DCB label, all segmentation points can demultiplex based on the same label so there is no need to re-advertise a new label.
Zzh> For comparison, when ingress replication is used, a PE or a segmentation point advertise a local downstream-assigned label towards the upstream via Leaf A-D routes, and the PMSI route does not carry a demultiplexing label.

18. I am missing capability indication in BGP somehow to make a PE indicate it even understands this new signalling type. What happens in mixed scenarios etc.

Zzh> Mixed scenario is not supported. I added the following at the beginning of "procedures" section:

                  When these procedures are used, all PE routers and segmentation
           points MUST support the procedures. It is outside the scope of this document
           how that is ensured.

Zzh> Thanks!
Zzh> Jeffrey


Juniper Business Use Only