Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

Eric C Rosen <erosen@juniper.net> Tue, 16 January 2018 16:31 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB7B1315E7; Tue, 16 Jan 2018 08:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2ofyH5g5GsU; Tue, 16 Jan 2018 08:31:05 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7E271131602; Tue, 16 Jan 2018 08:29:16 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0GGPmDb013737; Tue, 16 Jan 2018 08:29:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=A/N908lnjjbzyIcPIIzLdY5IkkrtQD6BIEPYOMwWgK0=; b=0KbVmLSIDRcIVwd6bBRPjk3C6QOAoOj9/aDsvkurhdJ/d6J29oij+AOOB0zo4JCHWqZE z5/SKTT/JV9uEWosyAACDRAkw3Zaq2UruFYkw7uY7jTVdqemC/ipxhJRDLxa8c+FFS7w Cjy0HsRfPkIzLfmgAo7zE9M38V8vvBwokYDFeU58+JxafNSIkZzavi902DhFCz+O48GN yKmbPasXg3Fx8if4CZROHZKbC33fMxn3uqxjeA2Sb6qAIlBTcWq3aI3xRNsklzchaPEp cya2JFD0HRwxwCynWxeiKk+jFwBDNlLGno2OiV1QCfShcgWVRLBN/1JnuybrCniCRX2e Ew==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0b-00273201.pphosted.com with ESMTP id 2fhmj382mm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 Jan 2018 08:29:13 -0800
Received: from [172.29.38.133] (66.129.241.12) by CY1PR05MB2300.namprd05.prod.outlook.com (10.166.192.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Tue, 16 Jan 2018 16:29:10 +0000
To: stephane.litkowski@orange.com, "draft-ietf-bess-mvpn-expl-track.authors@ietf.org" <draft-ietf-bess-mvpn-expl-track.authors@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>
References: <7712_1514984470_5A4CD416_7712_401_1_9E32478DFA9976438E7A22F69B08FF921EB01322@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <ecd0de7c-c395-2105-ab94-e1a9ca5381be@juniper.net>
Date: Tue, 16 Jan 2018 11:29:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <7712_1514984470_5A4CD416_7712_401_1_9E32478DFA9976438E7A22F69B08FF921EB01322@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------269282E6C4FBEFF74F908491"
Content-Language: en-US
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: CY4PR1001CA0004.namprd10.prod.outlook.com (10.171.218.145) To CY1PR05MB2300.namprd05.prod.outlook.com (10.166.192.146)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3ba2a0db-6e5f-4ca7-a3e6-08d55cfe4684
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:CY1PR05MB2300;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2300; 3:euGQC9RMrQfint70FMKT/APgCjceTQ19Rl/QlhnaEPzr1vwPzkBcABAp16nfb/mytnAeYXLSz6VUC5NIz4K4tE7kl2DVcB1bUgJLMfWZaHUUuQCVexyqFKDeTK0+RXoGB6q91uzVVxSulOTESkiv3b1sOoRSdqTrHY48duifo6MO55M6xG+XpzBoR+ZNvBjMutZi7h/FYAMN6ib5HPsFP9KUbA6NfB6oEjVTzi95ESBhkpGkJHuYKR9WzWxezUgb; 25:C1BrNI4faz5KuPwFZxchE+id2LwqYnQj+QUqVR0Yg73z2xPah4bENzqM+rMtmkANZYQQ+2Yrz0JJr7htE4BxwgU2baWoFZU8hUrgIHG9oFzHcWIleymkIhmwIS1fPfd/ISCwFuIU0iqtkaQIYYAek2ykGCXvefT/kzRsGcuUcgrpCFW8Pao3Y9d19SuKZeoSy5zERm0dq/nq8XY6n7yiO4iSv5PRQ0EHg6iAL32KHELrrDEdC/yDjTZGmYUH9ObaYR7yykYOabZhhsF0pcDqQ8RQpqG+78ejeZAm5TJ4y9lylRtT0gdXjVmg49/uSOwc8tBdXRDkLUl9hKSE7jrHzw==; 31:GYxr9xsIy9SGW20oV6nHSUncUz7x08reI2um+6iJOMhPwq+7fywQ+rl1M/E15NKXjG/WDolDPFSlSKWcdDGjAfB+zkDUwgnANmeC8jjQdcMDuKbfzOnjF6FJn9KbRh2eAE0DoMF3es0kIOcsLwWTj8/ayQgfZ+d4Bw2Tv5DgWtULECS5Qo3CpP2xrbbXPo4xSoHDLUIJAJnl/EnD4PIkpX1eMEEntnyLbwcIk0a+6+k=
X-MS-TrafficTypeDiagnostic: CY1PR05MB2300:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2300; 20:wM10dg1ncCjXnWhGE6pnRNlI4iRugbiJh0/oidfkOIiZcOAlekEw6NiSl/y5/MKWF8mlr6ECCGzijK8CuCePGA4t9mSB8ccFpKm7DBRIY5/ipwy28LI+GpfI3JYfxJESz3R82sQZljGad9nS2KcwFaMczzJd2tJyk+MgohERSW2b1/mYz+EFfPiu6y81nsk3jfqbuVHP3JevDyH/heCPpSSxd3U3HAmHkHGWt4t6F7peS8QoDFvAdlcL8QMSeYEsoD32oR7wI8NBxVnhaIaq0JpkY7TfE3/3lnXPQYhuN8drcNVv1bv2q5/ytfhoAPfwz8m0+Im+XvItlC9Q0BHl9YG76c3+xlQZr+6Q1S24bxCVsQ/4IAm/nW441RLQd0lXfHd4KazBCmUE3uRv42UVOGeK2LFP2hkOfoqLgrw+GdTnqcX8tOecVpBPrG7MVs6NiqXFhexeBgy7VyJibgJo+XS/+hiDLfcrZimgiX2VFw/RhMBd8j7TXvIU//3rI7KxYOum6meUMZsmgUVKwP7+bNciw9ofDPsHbLL/5ZErcB6bFOFSEAOizpGAVhRlf1liU56Wiz5L8dgRpV3S0U3XMCdl0fIX3wKEOPve2IJCo1c=; 4:jaBZeWP7jdirjHVZlKYtYkF66E8CpUuekQe/49QxVl+bPotQC2VopYiFV1UybW4YlCzr+KdCi2pEqM0Q+E6yZrIcpFf8Hx0Wx3TzBBBchc48pq+pbxDShqlJ1B9WeKeYqT/Py9Yyj6SoWVWOITtTm9A1c+MYBYM9H+c2iCRdd0zItZ2Jas1mb3Tc2csuKgHaUk06CqMqW3HWTjSBJeIJ4gw0qZRhesyJLl0Nv6xnfWlBYwAoKGnso9thkWkxy29DuWZlkvuUX5NA8w1ccJ402OPckqCj3Cp9jy65I10ybLrNR/zUr3XD7MulrqGmk/CL
X-Microsoft-Antispam-PRVS: <CY1PR05MB230048818BAF38EE6098B4D9D4EA0@CY1PR05MB2300.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(18271650672692);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(944501161)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR05MB2300; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR05MB2300;
X-Forefront-PRVS: 0554B1F54F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(396003)(39380400002)(376002)(346002)(39860400002)(189003)(43544003)(24454002)(199004)(51444003)(76176011)(59450400001)(53546011)(316002)(386003)(68736007)(105586002)(8676002)(8936002)(106356001)(52116002)(64126003)(65806001)(65956001)(230783001)(81166006)(81156014)(5660300001)(2501003)(2906002)(84326002)(6116002)(790700001)(3846002)(66066001)(86362001)(6246003)(236005)(54896002)(53936002)(25786009)(53946003)(3260700006)(2950100002)(4326008)(561944003)(65826007)(6916009)(31686004)(77096006)(6486002)(229853002)(90366009)(478600001)(26005)(16576012)(83506002)(97736004)(37036004)(54906003)(58126008)(16526018)(36756003)(16586007)(31696002)(7736002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2300; H:[172.29.38.133]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2300; 23:nJGJn/LSx0vEda9BRAo+/QH4QBlNWN+QLiAhri6JH?= =?us-ascii?Q?HoLm6xsKwiQthtmK2aLESxWau8ASznUanezqhzcAUK3Hv3O/Yr9GUuh8S3/Q?= =?us-ascii?Q?FA13+XuefxPZ8jDCGubEm/aOHJAUIOQltxpOYB0A5k0Qr3Z0v0fXYyF+BOmf?= =?us-ascii?Q?+Q4CmTTZPmiwRRGnR/iL7/DH0TO8sfNmdHT1vJzeePo3+2z0A37VZHX7nU99?= =?us-ascii?Q?k/6s+DcpywqIt314vs9ZM6twlN0igCpcd0s5VDgWu0f/TI/j0zdf0cqutL/s?= =?us-ascii?Q?+aZWlaLAwMRHnpOXby4EAL6X/vgqWPcA1dIrZExLR4mUOop/gAHyakuL3pn2?= =?us-ascii?Q?vjhNXCKfWUtyDUOtG+9WEg2NdVkknMjhKmqsmhJp04WJWAAfPIoQvq9EAkoU?= =?us-ascii?Q?ADed03Lp7NeOvJwuXwxF0JgvD6eO8+iO2GTNl8KG4j+sWLb6/MndNwC8YrIi?= =?us-ascii?Q?Zk8FDb6EFgBZLtf3JybBuXDLpts7yaYlJBtb6nH9RBd+KSbg1ZqvBYwdmG5n?= =?us-ascii?Q?bEEvpnFC+fXCpDdpMq3sgiCYYFOi0RyWtxq3aWY8+9IgTblXfa000IoYeJzP?= =?us-ascii?Q?fAhKGo+3XUfOrafIE2RUpUNMxxjOUzqx+Xp1cSDlYGUGXKB+qoeHXG+6Kmmn?= =?us-ascii?Q?qprKpVLRR2q3x65b+7DM+5Iv+NL0gwsEhWJ56XExne2OhhjwjGDV7bNluTgZ?= =?us-ascii?Q?Oy1ZLjo1IOvPlClgPBgq+wk0ZCz0k1VnRJtlkwfFnAWrrRUUej1kx9BtRrZe?= =?us-ascii?Q?U5Saz1Qyy/XKb8GqrZ9TLTQjK8LRuaWzjpaFjY1N5nUowqGXAuTI+FDv5Rxg?= =?us-ascii?Q?lXp4y5Dbx9lpcVnozIGbm2KLsqtSC2YJ/qep/ozFiMjWbvcyAeS/YTFRk6XU?= =?us-ascii?Q?hmqt/Sm33U+POwqdbeEEh+6f0QzHSy1L4DkhoT0/VkhtgML/DqJPDoW0a1OT?= =?us-ascii?Q?89jFOkpRlq6JCU/dMhUZm2YV7qPdxwaGCEFO39+kXpsG1i6LU4Fl8Eqgc9GO?= =?us-ascii?Q?HxXyyJlE6nZmiDidOxRltKi5W62K2J/YKfHLfGILSM7wf0djf0I+eoeeZw0I?= =?us-ascii?Q?4/JUvsKn6+BKPWV/ihcdeYKgBpwonqXPTGrlitpjdptfSKn8hlReZjTypw4c?= =?us-ascii?Q?hKgifxo4O8ZtkujLyUu4beyFw74+ZqotYb36VLyrRyBxcOEdQLT6lVdHpWD1?= =?us-ascii?Q?38Ex6TBdWDAALII5ySQMKCVkGsU/S7JnbaQA8GDjC7m4f0vDh4M40R9Oll8c?= =?us-ascii?Q?Php/tIWgmVrguUl/dYmR8lnVdCKAqcHclLHSi8vRtLySwSC0BbgBnvyR10hd?= =?us-ascii?Q?dWbotM5s++9GatsvDcRnLO+G+XTNy+b2/exJ13u/evJ76XJBwxqG23I23m/V?= =?us-ascii?Q?MAMRzvuDJglKBqgSm2WgM3RP6/LjcZQ00RsgChFMneIkE14wxQMcZEn38hli?= =?us-ascii?Q?V7AesY9OgcTq34MRs9YpbXSZpnSpQHHl0QQhhYpjF4oWYrtqWMgpd35B+n4n?= =?us-ascii?Q?9CABRRfBHUvacTq7VOQv0rbCdxFpbfQ/o5+ZdpZwSXr0frvWRNjticK4KCkV?= =?us-ascii?Q?hj9czS+3JEwPbiyvDFzMqyx+NnFrQWmgmRFlwA=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2300; 6:kuZDJ7H7p2dhM54UQnkjOWTpU3vFu+TfeT66X4yWy993CHI0MLFywUEQj4EKBHyU3kkJQPY4Ijd0y/+HMTJOn6zl2Dm5XBVhuwKKtqeCMWt0vG1Yc5XNFX+tfKtU2yMmS30Rt+OAuAI+aDK+vpNL/nh5KTb+PgilRkElDqigIw3oM4XIcXE7l0yzjORuvX0J66mdo8qpoyyOa7B9RyHb+FipuRL6PLkjgvFRKGA7PFUhrCUeJvfAUXSO42prgnOMitSgkporhamNnzjeDmYFxZh4+zq7J1XRZRUaxRdpPYQeLDrEzIuBaVzuBDxzICOLbnTPdTX2TdNVjny8s/FWL04ITSeKsFxyXiX7/o1GEKI=; 5:ArokKThNzRJbQedQgMwYqZ/Dqo75+Wmz0JG9RIxyNMyVaieH5RT2zhv67Mvpfzr1O0ybJVoUnhY536HZ1x6HorasvKWFSgLJu1434nvVL7PmtVu6mOctsApVM/paMDptdrVNODb7uoZjVVBQ86aCzrSCyaQt1viDyCmPO4LAWAI=; 24:mBwCBcQPC+HL+t/EyVS/KXWdn7lDEWuQfeceWWBAWPzZKD5qApbU0UCGT+w7sVpxVjch3YctnHdMJruzOYNOb1vZp0Ww4G0bEmbbyOSJ8es=; 7:oAlY7bbRL11TSe6/AgWac79eO+ZkGP2csNACLkQfUsnGTo63VfcD7QEs5oqZADPuuZpgqdtUsbiWnukmrrX7RA3qWNvtUOH84zLZpIUUn6INjRyiqDHylJOuT544PQBdwSmm3Q+MdQFpUu9HDtOClwyIhFERgjtZ7wcFv6ibDaXmUd7sC0UQ1apdEnHiABxDk9AHIn1H8E8CL3nuS8xbLwRQ1XbCgIX7oXVUaX8zaZpvbW0H/4641g64rsvvVGGe
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2018 16:29:10.9057 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ba2a0db-6e5f-4ca7-a3e6-08d55cfe4684
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2300
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-16_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801160229
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Ke1NRlUc840v6SFmt3THTyuzwvU>
Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 16:31:14 -0000

Thanks for your review.  I have posted revision -04 which I believe 
addresses your substantive comments.

On 1/3/2018 8:01 AM, stephane.litkowski@orange.com wrote:
>
> Hi,
>
> As shepherd of this document, please find below some comments that I have:
>
> Overall comments:
>
> -Please add a section that contains all the abbreviations expansions: 
> that may help non expert people to follow the acronyms without looking 
> for the first reference in the text.
>

This is not generally required of an RFC.

> -I usually like figures. For the intro, it may be wonderful to build a 
> figure that reminds the existing S-PMSI/Leaf A-D procedure. So without 
> reading the text, we can remember how it works.
>
> -The interAS case may also be better with a Figure and an example (or 
> couples of).
>

This seems like a matter of taste.  Admitedly, I'd probably like figures 
more if I had any skill in producing them ;-)

> Introduction:
>
> “By originating one of these BGP routes, an ingress node advertises that
>
>    it is transmitting a particular multicast flow.”
>
> [SLI] Is “is transmitting” correct ? Can’t we have situations where an 
> S-PMSI route is/was advertised but no traffic is flowing (no yet 
> started or switched, or stopped).
>

Fixed.

> “Now
>    suppose that the ingress node wants explicit tracking for each
>    individual flow that it transmits (following the procedures of
>    [RFC6625] on that P-tunnel.”
> [SLI] Missing “)”

Fixed.

> “This allows the
>    ingress node to determine the set of egress nodes that are receiving
>    flows from the ingress node.”
> [SLI] I think the Leaf A-D tells that there is a receiver interested 
> by the flow, but does not tell that it actually receives it.

Correct; fixed.

> “   Howver, this procedure requires several clarifications:”
> [SLI] There is a typo s/Howver/However/

Fixed.

> “The procedures of [RFC6625] do not clearly state how to handle an
>       S-PMSI A-D route if its NLRI contains wild cards, but its PTA
>       specifies "no tunnel info".”
> [SLI] I quickly ran over RFC6625, it does not mention anything on 
> explicit tracking or Leaf A-D routes.So we assume that RFC6513/6514 
> only applies here.

RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, but did 
not consider the case where the S-PMSI A-D routes do not carry a PTA.  
This document corrects that.

> “   *  The explicit tracking procedures do not allow an ingress node
>          to "see" past the boundaries of the segmentation domain.
>          This particular problem is not further addressed in this
>          revision of this document.
> “
> [SLI] Do you plan to address it ? Or do we now consider it as out of 
> scope ?

I think this is actually addressed in Section 5.3, so I've removed the 
remark.

> Section 2:
> “Prior specifications define one flag in the PTA, the "Leaf Info
>    Required" (LIR) flag, that is used for explicit tracking.”
> [SLI] Please point to the right reference

Fixed.

> “If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
>    SHOULD also be set.”
> [SLI] Why not using a MUST ?

If all the PEs support the LIR-pF flag, the procedures will work as 
intended even if the LIR flag is not set.  So I don't think a MUST is 
appropriate.

> “one forces a
>    a response to be sent an egress node that does not support LIR-pF”
> [SLI] Is there a missing word like ‘sent by an egress node” ?

Fixed.

> Section 3:
>
> “The definition of "match for reception" in [RFC6625] is hereby
>    modified as follows:”
> [SLI] Please point to the section that you are updating.
> In addition, section 3.2 of RFC6625 contains multiple if then else 
> conditions for each cases (C-S,C-G) and (C-*,C-G). Please give some 
> precision in where do you want to insert your new statement in this 
> processing sequence. I guess it is at the beginning.

I tried to make this clearer.

> “When finding the "match for reception" for a given (C-S,C-G) or
>       (C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose
>       PTA specifying "no tunnel information".”
>
> [SLI] I would be in favor to introduce a normative statement here.
>

Fixed.

> “We also introduce a new notion: the "match for tracking".  This
>    differs from the "match for reception" as follows:”
> [SLI] It would be better to give a definition of the “match for 
> tracking” before giving the rules. Here you’re explaining only the 
> rules, not the difference in the meaning. Wouldn’t it be easier to 
> tell that the implementation MUST consider only the S-PMSI A-D routes 
> that have a LIR flag and/or LR-pF flag set and then run the same rules 
> as the RFC6625. Why do you want to have S-PMSI routes with PTA and LIR 
> unset in your route list for “match for tracking” ? You need to take 
> care here on your text proposal as one of your previous statement 
> updates the RFC6625 and the match reception procedure, so the rules to 
> be applied are the original one from RFC6625 and not the updated one.

IMO, the clearest way to express this is to give the rules and then 
illustrate with a couple of examples.

> “   Also note that if a match for tracking does not have the LIR flag or
>    the LIR-pF flag set, no explicit tracking information will be
>    generated.  See Section 5.”
> [SLI] Again I do not see the value added of keeping such route as a 
> match for tracking as there is no tracking requested.

As the terms are defined, there is always a "match for tracking" route 
for each flow.    If tracking is not requested, this route will have LIR 
and LIR-pF clear.  There are no unnecessary routes.

> Section 4:
> “Such a route could be an
>        I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*)
>        S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. “
> [SLI] Is per flow explicit tracking also required for I-PMSI ? I do 
> not see it listed in the goals of the doc ? The goal was to address 
> wildcards S-PMSI AD routes.

The above simply says that some route must specify the tunnel on which 
the (C-S1,C-G1) is to be transmitted, and that this route could be an 
I-PMSI A-D route.

> “Further, if the ingress node originates a wildcard S-PMSI A-D
>
>        route carrying a PTA specifying the tunnel to be used for
>
>        carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit
>
>        set, then explicit tracking for (C-S1,C-G1) is requested by that
>
>        S-PMSI A-D route.  Thus the ingress node SHOULD NOT originate a
>
>        (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel
>
>        info"; such a route would not provide any additional
>
>        functionality.”
>
> [SLI] I do not fully understand this text in the context of your 
> procedure 1. which deals with an origination of an (C-S1,C-G1) S-PMSI 
> A-D route (no wildcard). As I understand the procedure for the 
> wildcard is defined in 2.
>

This just says that there's no point in originating S-PMSI(C-S,C-G) with 
LIR set if you've already originated S-PMSI(C-*,C-G) with LIR-pF set.  
That seems to be an appropriate bit of advice.

> “2. The following procedure can be used if (and only if) it is known
>
>        that the egress nodes support the optional LIR-pF flag.”
>
> I have some issue with this sentence. It does not seem to be normative 
> as there is no normative statement. However I understand it as a 
> critical thing (“and only if” !) so it may require at least a SHOULD.
> Then the issue I see is that this knowledge does not come from the 
> protocol, so it sounds important to me to highlight the impact of a 
> mistake.
> BUT, reading the section 5. I understand that it is not as critical as 
> it seems as the receiver will ignore simply the LIR-pF flag and apply 
> the standard procedure (LIR set).
> Please clarify the criticity to have or not this knowledge.

I added some text saying that procedure 2 may yield unexpected results 
if not all the PEs support LIR-pF, and that the procedure SHOULD NOT be 
used in that case.



> “       To terminate explicit tracking that has been initiated by an
>
>        S-PMSI A-D route whose PTA specifies a tunnel, the ingress node
>
>        re-originates the route without the LIR flag set”
>
> [SLI] Do we also need to clear the LIR-pf ? It would make sense to do so.
>

Fixed.

> “If the match for tracking has LIR set and if either (a) the
>
>        egress node does not support LIR-pF, or (b) LIR-pF is not set,
>
>        then the egress node must respond to the match for tracking,
>
>        following procedures specified in other documents for the case
>
>        where LIR is set.”
>
> [SLI] Please state the relevant document references here.
>

In the case described above, the handling of the LIR flag is not 
modified by this document.  I don't think it is necessary to cite a 
specific set of documents that discuss the LIR flag.

> Section 5.2
>
> “Note that, per RFC4364, every RD begins with a two-octet type field
>
>    that is either 0, 1, or 2.  By adding 16 to the second octet of the
>
>    RD, we force the type field to be 16, 17, or 18. “
>
> [SLI] It works but we may need to ensure that the types > 16 cannot be 
> used anymore by new applications.
>

There is  a registry for the Route Distinguisher Type field.  Only types 
16, 17, and 18 are defined here, other values are still available.

> Moreover if new RD types are created, new siblings will have to be 
> created.
>

Your point is correct, but there hasn't been a new RD type in 20 years.  
The draft shouldn't really say "add 16", it should just point out the 
new types.

> Wouldn’t it be easier to set the MSB of the RD type to 1 ? so we only 
> lock half of the type space.
>

I think it is easier to use three new type values than to turn one of 
the bits into a flag.

> Or what could be the impact of using the RD of the local VRF of the 
> egress node ?
>

The RD of the Leaf A-D route needs to be derived from the RD of the 
S-PMSI A-D route that elicits it.  Otherwise the ingress node receiving 
the Leaf A-D route will have diffculty matching it to the corresponding 
S-PMSI A-D route.

> Section 5.3
>
> “In the case where the egress
>
>    node is not a PE, but rather an ABR or ASBR, it will not know whether
>
>    it needs to receive a given flow unless it receives a Leaf A-D route
>
>    whose NLRI specifies that flow and whose IP-address-specific RT
>
>    specifies an address of the egress node.”
>
> [SLI] The sentence works but when reading it I needed multiple reread 
> to understand that the “IP-address-specific RT
>
>    specifies an address of the egress node.” was referring to the 
> ASBR/ABR and not the receiver PE.
>
> Do you mind using “this egress node” or “this ABR/ASBR” ?
>

I tried to clarify that.

> Section 8.
>
> [SLI] Do we have counter-measures against such “attack” ? Ingress PE 
> dropping ?
>

I consider the specification of such counter-measures to be outside the 
scope of the document.

> Section 9.2
>
> I think RFC7524 needs to be referenced as normative giving that its 
> knowledge is required to understand section 5.3.
>

I'm not sure that RFC7524 should be a normative reference, as this draft 
does not require segmentation at the ABRs.  However, since RFC7524 is 
already published, there's no harm in adding it to the "normative 
references" section.

> I think that section 5.3 is also updating/complementing the procedures 
> in RFC7524 with the “no-tunnel info” case.
>

There don't seem to be any clear and objective criteria for determining 
whether one document "updates" another.