Re: [mpls] Routing directorate review of draft-ietf-mpls-app-aware-tldp

Santosh Esale <sesale@juniper.net> Tue, 07 February 2017 23:28 UTC

Return-Path: <sesale@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DB512966D; Tue, 7 Feb 2017 15:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHHitYEOH7FA; Tue, 7 Feb 2017 15:28:18 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF05912965F; Tue, 7 Feb 2017 15:28:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UCSUC7CiCVTVCDXw/xy2IwA4cUCl9VV5IUg4xJ5WIP0=; b=Y6rKf2ZSurVXqLiE4JhTohbrb0k7kL1hq8KGbUnDWeQWeHKB3FnfX/aeGUQzwxeM1aWJ4pEXSJNFH1Jvj2r91KHSsjWUw4RayF3DmY0k9tYNRUrKPWXG49uygh3tAIxhFIjkhIWc1LBCT0aL4axD7y526GtbRr2gIg9x3yYkPGg=
Received: from CY4PR05MB2853.namprd05.prod.outlook.com (10.169.183.11) by CY4PR05MB2854.namprd05.prod.outlook.com (10.169.183.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 7 Feb 2017 23:28:15 +0000
Received: from CY4PR05MB2853.namprd05.prod.outlook.com ([10.169.183.11]) by CY4PR05MB2853.namprd05.prod.outlook.com ([10.169.183.11]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 23:28:15 +0000
From: Santosh Esale <sesale@juniper.net>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "draft-ietf-mpls-app-aware-tldp@tools.ietf.org" <draft-ietf-mpls-app-aware-tldp@tools.ietf.org>
Thread-Topic: [mpls] Routing directorate review of draft-ietf-mpls-app-aware-tldp
Thread-Index: AQHScPkugTFoNF/dc0yUfSsHVD0HaKFHzcYAgBX+BIA=
Date: Tue, 07 Feb 2017 23:28:15 +0000
Message-ID: <D4BE0BF3.E3C73%sesale@juniper.net>
References: <D4A3A262.E06A8%sesale@juniper.net> <15755_1485272289_588774E1_15755_6156_1_53C29892C857584299CBF5D05346208A1ED131C8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <15755_1485272289_588774E1_15755_6156_1_53C29892C857584299CBF5D05346208A1ED131C8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.0.161029
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-ms-office365-filtering-correlation-id: e0dacb9d-3e95-4014-9bad-08d44fb0fd7e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR05MB2854;
x-microsoft-exchange-diagnostics: 1; CY4PR05MB2854; 7:0ysuFg/5mi2EUgJ1yNO7jlBaxNvZ/uKq41mRUFWZCaMpPr04JrAlftKHtCjM6hF7JljbTY9h+17T7KYigPOmFAxx9LOHghHOydxr0RGZlaO/VaU1BWDU9fBdcW/XktFjnKH4mp7AjNfPbq4Os6k6gJlMaCwRogDAbdxavFOd6g1yXLJg2Wothxh1FT/EN2CPUi8o2gZHnD1eL34Rekvc8Q/MUkZtHXkHksyHAwCdbChF1B2UHQ8xjpyIdUd4h6CaK+KT0VzhsMpl2ZV46emWtLR+eLLC6U4shC0tHB0od3rvjNF1veu2fBdhQQnBDGra6l+NiVJvvPqOaTKxApo6sue548S3TM8NuoCxEPZhyOcDd89+cljlDlLZ1MjEJ2zwNC1lOi3nZENBOPRXWUBh6BaVRkTavtCyyjYWridI/MKXGTmkc+lXpp3Gpj/A/0VMzDXR/2m36qH0dvXzyNPKyi6rW5z7WJvZ1pmGwCOBE/1KwilV7pTFhwvIWF8acjboJhr3HUWCclEIuwPu32PSIw==
x-microsoft-antispam-prvs: <CY4PR05MB2854EF6DE14ED69376B67080D9430@CY4PR05MB2854.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(138986009662008)(100405760836317)(18271650672692)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(20170203043)(2017020603029)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:CY4PR05MB2854; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2854;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39860400002)(39840400002)(39450400003)(189002)(377454003)(199003)(51914003)(37854004)(24454002)(99286003)(54906002)(83506001)(2950100002)(106116001)(122556002)(105586002)(53546003)(6246003)(3660700001)(106356001)(38730400002)(2900100001)(54896002)(101416001)(236005)(6306002)(15187005004)(50986999)(54356999)(6512007)(76176999)(81156014)(81166006)(8676002)(4326007)(53946003)(6506006)(16200700003)(92566002)(8936002)(53936002)(2906002)(229853002)(5660300001)(86362001)(66066001)(230783001)(68736007)(4001350100001)(102836003)(790700001)(6436002)(7906003)(7736002)(606005)(2501003)(189998001)(6116002)(3846002)(36756003)(25786008)(97736004)(3280700002)(77096006)(6486002)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2854; H:CY4PR05MB2853.namprd05.prod.outlook.com; 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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D4BE0BF3E3C73sesalejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 23:28:15.0492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2854
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/4ByNaVvb11g3mpVIzn5E8_5xBc0>
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-app-aware-tldp
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 23:28:25 -0000

Bruno,
           Please see inline for answers.

Also, we will publish a new version addressing few more comments shortly.
On 1/24/17, 7:38 AM, "bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>" <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

Hi Santosh,



Thanks for the reply and update.

Most (>80%) of the points are addressed, thanks.

We may need additional iterations on some points, hence more inline [Bruno]


From: Santosh Esale [mailto:sesale@juniper.net]
Sent: Saturday, January 21, 2017 1:45 AM
To: DECRAENE Bruno IMT/OLN; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; draft-ietf-mpls-app-aware-tldp@tools.ietf.org<mailto:draft-ietf-mpls-app-aware-tldp@tools.ietf.org>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>
Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-app-aware-tldp

Hi Bruno,
                Thanks for the detailed review and apologies for the delayed response. Please find answers inline.

On 10/10/16, 5:56 AM, "mpls on behalf of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>" <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> on behalf of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-app-aware-tldp-05.txt<https://tools.ietf.org/id/draft-ietf-mpls-app-aware-tldp-05.txt>
Reviewer: Bruno Decraene
Review Date: 2016/10/10
IETF LC End Date: not started (AFAIK)
Intended Status: Proposed Standard

Summary:
I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.
Comments:
Draft is well readable. But I feel that it could be even more precise on normative behaviors (cf minor comments).
Clarified normative behavior in most the cases alluded in this review.
[Bruno] ok, thanks


Preliminary info:
- I'm not a LDP expert. Unfortunately, this may become apparent in the below comments. So you are welcome to disagree and provide the information and reasoning that I may be missing.
- Given that the required IANA code points have not been pre-allocated, I am assuming that no implementation of this document exists. Hence I'm not restricting my comments to minor comments.


Major Issue:
Abstract and Shepherd Write-Up defines the goal of the solution as advertising the purpose for sending this tLDP session request to the tLDP receiver, such that the receiver has enough information to decide to either accept or deny it.
I don't feel that the solution perfectly matches this purpose. First the solution requires that both ends of the tLDP session negotiate the _same_ set of applications. I don't see why this is needed to achieve the above goal.
 In LDP, negotiate is equivalent to both LSRs – initiating and receiving – sending their targeted application list to each other. And unless initiating LSR sends it's targeted application list to receiving LSR, the receiving LSR will be unaware of it.


[Bruno]

1)      “In LDP, negotiate is equivalent to both LSRs – initiating and receiving – sending”

What do you mean by “In LDP”?

If you are referring to LDP capability negotiation [RFC5561<https://tools.ietf.org/html/rfc5561>], it defines the negotiation of LDP capabilities, i.e. negotiation of the “Targeted Application Capability”. This is not what I’m commenting on, here. I’m commenting on the exchange of Targ. Appl. Id, which is defined in this document, hence subject to any new behavior that we want to define.

Okie.



2)       This is good that each speaker advertise its applications.

But why does this document create the restriction that both peers are required to advertise the same application, in order to be able to use that application, or even possibly establish the T-LDP session?

Because we want both the peers to agree whether they want to establish a tLDP session for a specific application.


This seems like a limitation for application with asymmetric requirements. e.g. Remote LFA where only one peer (the Point of Local Repair (PLR)) needs to supports RLFA and the other peer (the Merge Point (MP)) can be a vanilla node.

In this case, there is no requirement to advertise the same capability/Target Application.

The merge point need to advertise same application – Remote LFA -  to (1) convey to PLR that it can establish this tLDP session and (2) advertise FEC–label bindings only for a this application.




BTW, as a related point, could the document explicitly define, the semantic of advertising a TA. Indeed, for asymetric applications, there could be 2 meanings, a “client” side and a “server” side.

Using the RLFA example again, the PLR would need to advertise the meaning “I run the PLR “application” hence I would need your help to learn your IP label/FEC bindings”. The MP would need to advertise the meaning “I run the Merge Point “application”, hence I’m willing to advertise my IP label/FEC bindings”.

Note that a node may run the MP application but not the PLR application. That should not avoid the set up of the T-LDP session or FEC exchange.

This document already defines the semantic of advertising TA, however not in the way as you have described. If both initiating and
receiving LSR negotiate a specific application or set of applications then they (1) establish a tLDP session between them and (2)
advertise FEC-Label bindings pertaining to negotiated applications only. For Instance - for remote LFA application, if both of them
negotiate remote LFA TA, then they  (PLR and MP) (1) establish a tLDP session and (2) advertise IPv4 and IPv6 FEC-Label bindings
only.  Further, a MP may use RFC 7473 to ask PLR to not to sends its FEC-Label bindings. It simple and it covers uses cases of every
application and not just Remote LFA.





Plus I find this problematic for some applications with asymmetric requirements (e.g. RLFA), in particular for incremental deployment of future asymmetric application. (more comments on this in the minor issues)
In addition, I don't see how the additional FEC filtering helps fulfilling this goal.
FEC filtering is used to advertise only necessary LDP FEC-label bindings over the session. This is additional goal, and not the same, of the document.


[Bruno] ok.


I also find it redundant with RFC 7473. I also don't think that this FEC filtering should be symmetrical (e.g. RLFA application).
In short, I would have made the TAI advertisement asymmetric, and removed the FEC filtering.
We have explained clearly how RFC 7473 is inadequate to address both these goals in section 4.


[Bruno] I did read the draft, including section 4, so the answer is not that helpful.

I’ll defer the discussion on this point, until the draft/authors clarify the semantic of advertising a TA. (cf point above.), otherwise, we would be mixing 2 problems.

As clarified above. Also, the semantics are clear in the draft. If not, please point out how that can be clarified based on all the answers that we have given here.




Finally, if the goal is to allow the receiver to limit incoming tLDP sessions, presumably for scalability purpose, if one application is allowed and hence the tLDP session is set up, what would be the reason to limit the applications exchanged over this session?
We limit the application exchanged to the negotiated application list. Use case 5.3 precisely answers this question.

[Bruno]

- use case 5.3 is precisely detailing an example where 1 application is allowed and another rejected, but yet both applications are being enabled on the session.

- again, the motivation for this draft, as written in this draft (abstract and introduction) is to allow the receiver of a T-LDP session to learn the reason of this T-LDP session request, in order to better control its acceptance or reject. So as per this goal, once the session is set up (and hence the cost for this additional session is accepted) what would be the reason to limit the number of application using this T-LDP session?

In order to control the number of FEC-Label bindings advertised over this session. They consume most resources. If set of application need same FEC-Label bindings,
then both the LSRs can negotiate that set of TA without additional cost- example use case 5.3 . However, if the two application need different set of FEC-Label bindings,
then both of those application need to be negotiated based on local configuration.


IOW, why limiting the applications to the intersection of both advertised and received set of application?
This helps to advertise only the necessary fec-label bindings over the tLDP session, reducing the unnecessary fec-label binding advertisements.

[Bruno] Can you clarify why RFC 7473 is not enough for this? As this is a priori its exact goal.

Again with RFC 7473 , the receiving LSR is unaware to targeted application. Thus, it does not know
what all application it need to block and what all it need to allow. The example that I have given
with a figure at the end of this email answers this question.



Note that §5.3 lightly refers to this problem, but in a very application specific way (and not really normative), while the consequences could probably be made general. Especially given the pre-existence of RFC 7473 which can be used to limit the FEC advertisements.
Again, we have made it ample clear why RFC 7473 is not sufficient. First and foremost, with RFC 7473, receiving LSR is unaware of the targeted application. Thus, It has only two choices, either block or unblock all FECs that are advertised to it considering it is a passive LSR.


[Bruno] Looks like “ample clear” is not enough for at least one reader.

By “passive LSR” I assume that you mean passive in term of LDP session initialization.

No. Passive here means it is only supporting the establishment of the tLDP session from the initiating LSR.
For example the MP incase of Remote LFA.


Eventually the problem is application specific and we don’t have the same one in mind, this may explain why we are not in sync.

Hence I would assume we are in Sync :) including your below statements !


For the following applications “LDPv4/v6 Tunneling, LDPv4/v6 Remote LFA” the initiator of the LDP session is the LSR using a tunnel toward the receiver, and hence needs to learn the LDP labels of the receiver.

On the receiver side, it doesn’t need any info, and hence can request FEC filtering using RFC 7473.



Now with the applications “LDPv4/v6 Tunneling”, both LDP nodes (A, resp. B) may have a tunnel with the other (B, resp. A) but this does not change the problem: both knows the FEC that they want to receive.





Most of these points are addressed in detail answering questions towards the end of this email.

Also, we have updated the draft addressing comments, which will be published in next few minutes.

Minor Issues:
§6 "Security considerations"
TAC negotiation seems to allow an entity to remotely discover the targeted LDP applications running on a remote node. This is a new security consideration which should probably be discussed.
No. Currently, the remote node implicitly knows anyway all the applications that are running on source node based on LDP FEC label bindings. Note – Currently, LDP advertise all FEC-label binding over a tLDP session.
[Bruno] The TA advertised is more detailed than the type of FEC advertised. e.g. there are 3 TA mapping to IPv4 prefix. Hence this is additional information been advertised. e.g. an T-LDP node can learn that its peer runs RSVP-TE or RLFA or LDP ICCP... How much this can be used for an attack vector, I don’t know, but it may be useful to an attacker.


Also, given that multiple applications maps to the same FEC, two peers in different ASes could try to cheat, by successively trying multiple applications mapping to the same FEC. (e.g. if I want IPv4 FEC mapping, I would try with "LDPv4 Tunneling", then "LDPv4 Remote LFA", then "IPv4 intra-area FECs", then possibly "LDP session Protection"). This is also not discussed.
The initiating LSR MUST only advertise what is supports – IOW, what it is configured for – over the tLDP session.  It is clearly stated in section 2.2 first paragraph.
[Bruno] An attacker, or less trusted speaker in a different Autonomous System may not comply with your “MUST”. Unless you restrict the usage of this solution to only intra-AS LDP session, with mutual authentication. If so, such restriction should be stated in the draft.
Okie. we have added a line about it in the security section last paragraph.


----

§7 "IANA Considerations"
"0x0001 - 0x1FFF  Available for assignment by IETF consensus"
According to https://tools.ietf.org/html/rfc5226#section-4.1 "IETF Review" is the new name for "IETF consensus"
Updated.



[Bruno] ok



"0x7FFF - 0xFFFE  Available for vendor specific private use"

- This look like a very large range for a private use (half of the registry)
- "vendor specific private use" is not a Well-Known IANA Policy as defined in  https://tools.ietf.org/html/rfc5226#section-4.1 . Is there any definition of this Policy or should you describe it? How is code-point collision supposed to be avoided in deployments? (I'm guessing that this is coming from RFC 5036 IANA section, but RFC5036 seems to have a "vendor-ID" field to differentiate vendors, which is not the case of this document.)
On my side, I'd rather provision 2 very small pools for experimental and private-use. (i.e. private to the user/ the network provider.)
Thanks for the suggestion. Updated the draft to allocate two small ranges of 1k each for experimental and private use.

[Bruno] ok.

Is there a reason to start the range at 0xF7FF (resp. 0xFBFF) rather than 0xF800 (resp. 0xFC00)? It would a priori be easier for human to start on digit

Updated.

----

§1 "Introduction"
"Applications such as Remote LFA and BGP auto discovered pseudowire automatically initiate asymmetric extended discovery to any LSR in a network based on local state only."
I agree that Remote LFA is asymmetric.
I've not been following the work on BGP auto-discovery, but I would have a priori assumed that both tLDP end points are running BGP autodiscovery and hence the discovery is symmetric.
 BGP auto discovery is not always asymmetric. For example – BGP auto discovered multisegment pseudo wire can have different forward and reverse auto-discovered path to signal a tLDP session.


[Bruno] ok


----

§2.1 "Encoding"

"Targeted Application Identifier (TA-Id): a 16 bit Targeted Application Identifier value."
According to the figure just above, the field seems to only have 15 bits. (As bit 0 is used for the E-bit). If so the IANA registry would also need to be modified. Otherwise, the figure needs to be fixed.
Correct. There was a problem with the figure. Updated.


[Bruno] ok

It feels strange not to align a 16 bits field on octet boundary and instead spread it over 3 octets, while 2 would have been enough. Especially since simply swapping two fields (E-bit, TA-ID) would address this. Any reason for this?

Good point. Updated.



----
§2.2 "Procedures"
"The TAC TLV's Capability data MUST consists of none, one or more TAE"
:s/MUST/MAY   ? (otherwise, It's not clear to me what is the mandated behavior since all possible behaviors seems allowed)

Updated.


[Bruno] ok


----
§1

"For an application such as FEC 128
   pseudowire, the remote LSR is configured with the source LSR address
   so that it can use that information to accept or ignore given tLDP
   Hello.

   Applications such as Remote LFA and BGP auto discovered pseudowire
   automatically initiate asymmetric extended discovery to any LSR in a
   network based on local state only. With these applications, the
   remote LSR is not explicitly configured with the source LSR address.
   So the remote LSR either responds or ignores all tLDP Hellos."

 The introduction seems to imply that this document would give a remote peer additional information in order to accept or ignore tLDP hello.
My limited understanding of LDP capability is that they are exchanged  in Initialization and Capability messages, i.e. not in Hello message.
Hence it's not clear to me how this document helps the remote LDP speaker in deciding to accept or ignore tLDP hello.
Procedure section 2.2 explains how to achieve it as follows - "Also, currently the remote LSR accepts asymmetric extended Hellos by default or by appropriate configuration. With this document, the LSR MUST accept tLDP hellos in order to then accept or reject the tLDP session based on the application information.”


[Bruno] OK but the draft says that currently/before this draft, "the remote LSR either responds or ignores all tLDP Hellos".

My comment is that this draft does not change this, since it proposes de procedure _after_ the exchange of Hellos. Therefore, even with this draft, "the remote LSR either responds or ignores all tLDP Hellos".

No. With this draft, the remote LSR MUST accept tLDP hellos so that it can later accept or reject the tLDP session based on the application information.

So in short, I don't feel that this last sentence if a good motivation/introduction to the new procedure introduced in this draft.


----
§2.2
"   If there is at least one TAE common between the TAC TLV it has
   received and its own, the session MUST proceed to establishment as
   per [RFC5036]."

I'm not sure this is “as per [RFC5036]” since this document defines additional rules to define which FEC mapping needs to be advertised, and whether or not to accept the session.
It is in the reverse order. From RFC 5036 section 6 “The document specifying procedures for the capability MUST describe the behavior in this situation. If the specified procedure is to terminate the session,then the LDP speaker SHOULD send a Notification message to the peer before terminating the session.”


[Bruno] OK


---
§2.2
"The TAC TLV's Capability data MUST consists of none, one or more TAE"
It's not clear to me what is the use case to advertise none TAE, given that in this case, the intersection of the received and sent TA-Id will be null and hence the tLDP session will be closed by any of the tLDP speakers.
The use-case is for receiving LSR playing the active role in tLDP session establishment. If the receiving LSR does not have any configured tLDP application and do not want to support any tLDP session establishment, it will send TA-Id as null. The initialing LSR after receiving the TA-Id as null and playing the passive role in tLDP session establishment will then tear down the tLDP adjacency, eventually leading to the destruction of tLDP session.


[Bruno] I guess that the first  "receiving LSR" is not the same LSR as the second "receiving LSR".

I would assume that if it does want to support any tLDP session establishment, it could refrain from sending T-LDP hello, and/or responding to the tLDP session establishment, and/or just closing the T-LDP session.

But ok, this makes sense to allow the sending of none TAE. Let’s forget my comment.



---
§2.2
"If the receiver LSR receives an unknown TA-Id in the TAE, it MUST silently ignore such a TAE and continue processing the rest of the TLV."
Assuming the receiver (node A) supports Non Stop Routing and is upgraded to support a new TA-Id should it check for the previously received TAE that it has silently ignored or does the speaker (node B) supposed to re-send all it's TA-ID if it receive new TA-Id from node A? My reading of the end of section 2.2 is that in this case the receiver must checked from previously received TAE.
May be :s/receives/received  would be enough to address this case. Or preferably adding a sentence.
Updated.


[Bruno] OK


---
§2.2
"In the last instance, suppose the
   initiating LSR advertises A, B and C as a TA-Ids and the responding
   LSR advertises D and E as TA-Ids, than the negotiated targeted
   applciations as per both the LSRs are none. The Responding LSR sends
   'Session Rejected/Targeted Application Capability Mis-Match'
   Notification message to the initiating LSR and may close the
   session."

I'd prefer having normative text stating the required behavior rather than having an example.
i.e. I'm looking for a text similar to "If the intersection of the sets of received and sent TA-Id is null, then LSR MUST sends 'Session Rejected/Targeted Application Capability Mis-Match'
   Notification message to the initiating LSR and close the session."

   or :s/MUST/SHOULD or :s/MUST/MAY   as you wish
Updated.


[Bruno] OK


---
§2.2
"If it sets the session setup retry interval to maximum, the session MAY stay in a non-existent state."

If this refers to the LDP FSM, RFC 5036 used the term "NON EXISTENT" rather than "non-existent"
Updated.


[Bruno] OK

---
§2.1
This section mixes copy of previous specifications (e.g. RFC 5561) with the new specification. Personally, I'd prefer that the document be clear on the part which are reused unchanged and the part which are new specification. In general, I personally don't think that  this is a good practice, as it becomes unclear which document is the normative definition. And in particular in this document, there is a copy/paste error during the copy from RFC 5561, so it my be unclear if the goal is to redefine RFC 5561 or not. ("Typ" field has been increased by 1 bit and the "Length" has been decreased by 1 bit)

I would propose the following change:

OLD:

   An LSR MAY advertise that it is capable to negotiate a targeted LDP
   application list over a tLDP session by using the Capability
   Advertisement as defined in [RFC5561].

   A new optional capability TLV is defined, 'Targeted Application
   Capability (TAC)'. Its encoding is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Targeted App. Cap.(IANA)|             Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|  Reserved   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     ~                 Targeted App. Cap. data                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     As described in [RFC5561]
     U: set to 1. Ignore, if not known.
     F: Set to 0. Do not forward.
     S: MUST be set to 1 or 0 to advertise or withdraw the TAC TLV
        respectively.

     Targeted Application Capability data:
       A Targeted Applications Capability data consists of none, one
       or more 32 bit Targeted Application Elements. Its encoding is
       as follows:

       Targeted Application Element(TAE)

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|    Targ. Appl. Id           |       Reserved                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Targeted Application Identifier (TA-Id):
       a 16 bit Targeted Application Identifier value.

       E-bit: The enable bit indicates whether the sender is
       advertising or withdrawing the TAE. The E-bit value is used as
       follows:

         1 - The TAE is advertising the targeted application.
         0 - The TAE is withdrawing the targeted application.

     The length of TAC depends on the number of TAEs. For instance,
     if two TAEs are added, the length is set to 9.

NEW

   An LSR MAY advertise that it is capable to negotiate a targeted LDP
   application list over a tLDP session by using the Capability
   Advertisement as defined in [RFC5561] and encoded as follows:

         0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F| TLV Code Point            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |                                               |
      +-+-+-+-+-+-+-+-+       Capability Data                         |
      |                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                This document defines a new optional capability TLV of type TBD1 called 'Targeted Application
   Capability (TAC)'.
   Flag "U" MUST be set to 1 to indicate that this capability must be silently ignored if unknown.

   It's encoded as follows:

       Targeted Application Element(TAE)

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|    Targ. Appl. Id           |       Reserved                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Targeted Application Identifier (TA-Id):
       a 16 bit Targeted Application Identifier value.

       E-bit: The enable bit indicates whether the sender is
       advertising or withdrawing the TAE. The E-bit value is used as
       follows:

         1 - The TAE is advertising the targeted application.
         0 - The TAE is withdrawing the targeted application.


Updated.


[Bruno] OK

---
§2.2
"If the tLDP session changes to link session, a LSR should withdraw it"...
:s/should/SHOULD
Updated.


[Bruno] ok, yet the same comment applies to the next sentence

OLD: if the link session changes to tLDP, a LSR should advertise

NEW: if the link session changes to tLDP, a LSR SHOULD advertise

Updated.



..."with S bit set to 0, which indicates wildcard withdrawal of all TAE elements."
Where is this behavior defined?
My reading of RFC5036 is that sending the capability with the S bit set to 0 means withdrawing the capability. In which case this documents states that "If the receiver LSR does not receive the TAC TLV in the
   Initialization message or it does not understand the TAC TLV, the TAC negotiation MUST be considered unsuccessful and the session establishment MUST proceed as per [RFC5036]." i.e. the tLDP sessions stays up.
This is not the same as "wildcard withdrawal of all TAE elements" which means that the TAC capability is advertised with no TA-Id, it the tLDP sessions will be closed.
Correct. Removed this part of the text "which indicates wildcard withdrawal of all TAE elements"



[Bruno] ok,


--
§2.2

OLD:
   "Also, currently the remote LSR accepts asymmetric extended Hellos by
   default or by appropriate configuration. With this document, the LSR
   MUST accept tLDP hellos in order to then accept or reject the tLDP
   session based on the application information."

What is the goal of this paragraph? I'm reading that a LSR may not be configured anymore to reject tLDP hellos. Why not?
I would propose
NEW
"By default, LSR SHOULD accept tLDP hellos in order to then accept or reject the tLDP
   session based on the application information."

Updated.


[Bruno] ok,

---
   §2.3.1
"    1. The S-bit of the Targeted Application Capability TLV MUST be
     set to 1 to advertise Targeted Application Capability and
     SHOULD be ignored on the receipt."


This behavior is defined in RFC 5561. I don't think that it's good practice to redefine it.  I'd rather have this sentence deleted. Alternatively, it should be made non normative and refer to RFC 5561.
Updated.


[Bruno] ok,

---
§2.3.1
" 2. The E-bit of the Targeted Application Element MUST be set to 1 to
     enable Targeted application and SHOULD be ignored on the receipt.               "

I understand that you are mimicking the behavior of the S-bit. It looks debatable to ignore this direct protocol violation and accept the TAE while the speaker expressed its williness to withdraw it. I would personnaly be enclined to ignore the TAE advertise with the E-bit cleared.
This is the first time the peer is sending TAE in the initialization message. If it is not advertising it, there is no point in sending it.


[Bruno] Equally, if the receiver is not listening to the "E-bit" there is no point in sending it ;-)

I agree that "The E-bit of the Targeted Application Element MUST be set to 1". But I find debatable that "SHOULD be ignored on the receipt", because you seem to ignore a protocol error. And besides, the sender said "I'm withdrawing" and on the receiver side, you are translating as "I'm advertising", which are opposite message.

Shouldn’t be considered as a protocol error and handled as such? A priori by sending a notification with an error code.


Thus, Its a fair assumption that the peer wants to advertise this TAE.


[Bruno] Yes, a priori. But in this case, the peer is expressly sending that it is _not_ advertising TAE but withdrawing TAE. And you choose to silently do the opposite.

IOW, there is no place for assumption, when something is expressly stated

Fair point. However, since we have same semantics for the S bit, we will keep the same for E bit.





---
§2.3.2
"     If the S-bit is set to 0, the TAC is disabled for the session.
     After that, the session may remain in established state or
     torn down based on [RFC5036] rules."

IMO, if TAC is disabled, the session MUST behave as per RFC5036 rules. (in particular, I don't see a reason to tear down the session, but I do see a reason to advertise all FEc mappings which where previously filtered based on TA-Id negociation.)
This could be automatic session. Before this draft, LSR use to either accept or deny such session based on local configuration.
Hence, if the TAC is not negotiated for a session, the LSR may decide to bring down the session.


[Bruno] Since you are not specifying anything new with the last sentence, I would propose to remove it.

OLD:

  4. A receiving LSR processes the Capability message with TAC TLV.

     If the S-bit is set to 0, the TAC is disabled for the session.

     After that, the session may remain in established state or

     torn down based on [RFC5036] rules.



NEW:

  4. A receiving LSR processes the Capability message with TAC TLV.

     If the S-bit is set to 0, the TAC is disabled for the session.





And if you want to add some text, IMO it would be more useful to state that if the session stays up, all the FEC which had been filtered based on the TAC negociation, must now be re-advertised.


Updated the text.


[Bruno] I'm not seeing any update.

Updated.


---
§2.3.2
  "5. If the S-bit is set to 1, a LSR process a list of TAEs from
     TACs capability data with E-bit set to 1 or 0 to update the
     peers TAE. Also, it updates the negotiated TAE list over the
     tLDP session."

What's new compared to the already defined points 1, 2 and 3?
If this point 5 is kept:
  :s/peers/peer's
  What does the second sentence adds to the first one?
Updated. Removed the second sentence.


[Bruno] ok


§3
Personally, I would prefer that the array also include the normative code points (rather than requiring an indirection in the IANA section)
I will keep it that way for simplicity. It also avoids updating two places when the code point changes.


[Bruno] simplicity of one editor vs simplicity of 10s readers ;-)

But ok.

:)


§2.3
Why does the document mandates that TAE be symmetrically negotiated?  Here we are not negotiated capabilities which requires both ends to support the capability before its usage. We are mostly advertising the willingness of one LSR to receive FEC mappings from its peer.
There are two goals. (1) Both initiating and receiving LSRs know about the supported targeted application over the session. (2) Advertise FEC-label bindings only for those targeted applications.


[Bruno] Both goals do not seem to require that both speakers advertise the same TAE

It is a explicit and simple semantics to achieve both the goals.


e.g. let's take the RLFA application which has asymmetric needs. The PLR is willing to get the IP prefixes mapping from the merge point (PQ node). But its peer (the merge point) is not willing to get any mapping. So why would it need to receive mappings of no interest, and why would it need to advertise TAE which does not itself?
Let me answer your question in two parts - (1) The merge point needs to know that the PLR is establishing the tLDP session for R-LFA.


[Bruno] In order for the current version of this document to work, yes.

However, when I'm deploying RLFA, what I first want is RLFA to work. And RLFA does not require that the PLR support RLFA.

Your document brings a new requirement which is that the PLR needs to be upgraded to understand the R-LFA  Targeted Application. This an additional requirement for the deployment which will makes the deployment of RLFA harder. Plus this may be an issue because Merge Point may be node which do not support RLFA (e.g. "legacy node") or which will be upgraded later.

However, since you have added in the draft that a LDP speaker SHOULD be allowed to be configured with any TAI, this addresses my issue with incremental deployment of asymmetric features/applications.

So point addressed.


Based on that it may allow the merge point to establish the tLDP session or it may not allow if it has reached the maximum limit for the automatic tLDP session for remote LFA. (2) Once when they establish the tLDP session, we only advertise IPv4 or IPv6 FEC-label bindings over the session. Given the merge point do not need any FEC-label bindings, it may then use the RFC 7473 to request PLR to not to send any FEC-label bindings to it.

[Bruno] The Merge Point knows that it does not need any FEC, without the need for TA. Hence it can already use RFC 7473 to limit FEC advertisement to what it needs. Or am I missing something?
The same session could be used for other application for instance BGP auto discovered pseudowire. Thus, it does not know whether it should stop receiving all type of FECs. Hence TA negotiation is crucial so that merge point
knows what all applications are using this tLDP session and what type of FEC-Label bindings it should receive and not receive.

 Therefore, this draft helps to advertise what is necessary over the tLDP session, avoiding the advertisement of other FEC label bindings such as FEC128 and FEC129.

The document could have chosen an asymmetric model, where the advertisement of a TAE means "I'd like to receive the corresponding FEC mappings"
Explained above.


Coming back to the RLFA use case, this requires configuring the Merge Point with the willingness to advertise RLFA application, including when RLFA in not configured on this node. So this is additional configuration requirement. In addition, RLFA is designed to be asymmetric in nature, with feature requirement only on the local node. Such document would now require some support for RLFA awareness on the MP node which is undesirable.
I don’t think so. It actually the apposite. As the merge point do not know about why the PLR is establishing the tLDP session to it, it has no control over these sessions. This is practical deployment problem of a remote LFA today.


[Bruno] I don’t see where you can disagree on my 2 sentences. Please be more specific.
As of today, there is absolutely no requirement for the Merge Point to be aware of RLFA.
Obviously, if you assume that you want to limit the number of T-LDP session to support the RLFA application, then you need TA advertisement. But this is additional requirement. And typically not one required at the beginning of RLFA deployment, when scaling is low.

However, since you have added in the draft that a LDP speaker SHOULD be allowed to be configured with any TAI, this addresses my issue with incremental deployment of asymmetric features/applications.

So point addressed.


I guess that this is not too bad to RLFA which is a pre-existing application, but what about future applications which would also be asymetric?
The very purpose of this document is to make the receiving LSR aware of targeted LDP application. Given that, it has more control over these tLDP sessions and corresponding fec-label bindings advertised over them.

[Bruno] Good. But there are solutions (e.g. RLFA) which do not require any specific support on its t-LDP peer. Hence requiring a new feature would slow incremental deployment. Again, this point is addressed by your addition of the ability to configure any TAI.

§4
"With the SAC, the responding LSR is not aware of
   targeted applications. Thus it may be unable to communicate its
   interest or disinterest to receive state information from the peer."

Sorry but I fail to see the logic or the use case. One is a priori capable of communicate its (_own_) interest, independently of the ones of its peer. e.g., If I'd like a beer in a restaurant, I ask for a beer. (I don't need to wait for the menu, so see whether I wan't a beer)
I wish everything is as simple as ordering a beer that we love :)
For instance – Lets take a example of BGP auto discovered multisegment pseudo wire with different forward and reverse auto-discovered tldp path through the network.
 R1---------R2---------R3
|                |               |
R4---------R5----------R6
Forward path - R1 to R2 to R3. Reverse path - R3 to R6 to R5 to R4 to R1
[Bruno] ok. Not the simplest example ;-) and not one that I master, but I’ll try anyway.
In such a case, R1 will establish a tLDP session to R2 for forward path. Here R2 can’t decide what it wants.
[Bruno] In my understanding, R2 knows that it does not need any FEC bindings: hence it could suppress all IP FEC reception by using rfc7473
Since R2 does not need any FEC–Label bindings,  it will either blocks or allows every type of FEC-Label bindings using RFC 7473.
If  it blocks, then R1 cannot send FEC 129 label bindings to R2 and the multi-segment pseudowire cannot be established.
If it allows, It will allow even IP fec label bindings from R1.

R2 simply accepts all the fec-label bindings that R1 advertise including ipv4 fec-label bindings. With this draft, R1 and R2 knows that the tLDP application is BGP auto discovered pseudowire. So they exchange only FEC 129 label binding over the session avoiding the unnecessary IPv4 fec-label bindings.
[Bruno] It seems to me that without this draft,
- R1 knows (via BGP auto discovery) that it needs FEC 129 mappings from R2.
R1 knows that it needs to send FEC 129 mapping to R2. R2 does not know anything.
It is apposite of remote LFA.

Hence it set up a T-LDP session with R2 and suppress all FEC types, but FEC 129 ones, using rfc7473
- R2 knows (via BGP auto discovery) that it does not need FEC 129 mappings from R1. Hence, it does not initiate the set up of a T-LDP session with R2. But when it receive the T-LDP session request from R1, it still know that it does not need any FEC and hence suppress all FEC types, using rfc7473.

I’m probably missing something on this example, but hopefully, you’ll pinpoint it.
As explained above.




"  Therefore, when the responding LSR is not aware of targeted
   applications such a remote LFA and BGP auto discovered pseudowires,
   TAC mechanism should be used and when the responding LSR is aware
   (with appropriate configuration) of targeted applications such as FEC
   128 pseudowire, SAC mechanism should be used."

Well, as already expressed, I don't feel that TAC is well suited for the RLFA application as it adds the requirement to configure both ends. (more specifically the Merge Point). In which case, as per your above text, SAC should be used instead of TAC.
If LDP has already a way to control FEC/state advertisement (as per RFC 7473), I feel that adding the same functionality in TAC is redundant.
Already explained. In summary, this document makes receiving LSR aware of targeted LDP applications and only advertise FEC-label bindings for those negotiated tLDP applications.
[Bruno] I’m much more aware of the RLFA example. I’d welcome an RLFA example where mpls-app-aware-tldp would be useful.
to control the number of automatic tLDP session on the receiving LSR so that it is not overloaded with all of these automatic tLDP sessions.


---
§4
"The set of
   applications negotiated by the TAC mechanism is symmetric between the
   two LDP peers."

ok. for the _negociated_ applications.

"In the absence of further mechanisms, two LDP peers
   will both advertise state information for the same set of
   applications."

What do you mean by "state information"? At first reading, I understood "TAE" but this would be incorrect. So now I guess that you mean "FEC mappings"

Yes, FEC mappings.


[Bruno] ok. Could this be clarified in the SAC definition in section 1.2? i.e. what “states” refer to?

Updated.


---
Usage (new section)
To allow for incremental deployment of new TAI as well as private usage by a network operator, I think the configuration SHOULD allow the configuration of any TAI (including the ones unknown from the implementation) on both the sending side and the receiving side.
Added a text to procedural section 2.2 last paragraph.

[Bruno] ok, thanks.
New text says: “In addition, LSR SHOULD allow the configuration of any TAI in order to facilitate private TAI's usage by a network operator.”
“private TAI’s usage” could be understood as TAI in the private range (“0xF7FF - 0xFBFE Available for private use”)
You could this be changed to “in order to facilitate incremental deployment of new TAI representing usages unknown to the implementation.”
Updated.

Thanks

---
§4
"The TAC mechanism MUST
   take precedence over the SAC mechanism with respect to enabling
   applications for which state information will be advertised."

Is this not a case where the document meta data should indicate that this document updates RFC 7473?
---
Updated.

[Bruno] ok

§3
"IPv4 intra-area FECs"
Is this just a name of application, or is there a specific behavior associated with it? (e.g. only advertising the IPv4 FEC from my an area.) If so, the behavior should be specified. And please clarify whether this is the area of the sender or of the receiver, as in the general case, they may be in a different area. And clarify the behavior for IS-IS level 2 nodes.
We would add some text to address it.

[Bruno] I’m not seeing any new text.
Just published a new version with the updates including this one.


Thanks for the detailed answer, all the points already addressed, and the examples provided to hopefully clarify the remaining points.
--Bruno

Thanks
Santosh