Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)

Santosh Esale <> Mon, 26 June 2017 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B66312EB79; Mon, 26 Jun 2017 15:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yCa6AuQv_kGi; Mon, 26 Jun 2017 15:54:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABFB1127201; Mon, 26 Jun 2017 15:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZGWnndfs++bMTrxt/Gx+/wncquBjcIAzHzQyTKMIk3Q=; b=H8UrnetWl7MaoCs1SoRy/uPtTfD965k/hXdw9tvOU2rzt1j9hHNlsOsRHyJZx1XehmZVavNHNr1qD+Fp5PMS7/8xCRlGK3azz2Q9tbk2qQ0+Y/ZP1MiQoi3Uu+txpThJ7a5YxGUcMy9NintZ8a0gXVsFFidMZR/5icik4DRVGmI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Mon, 26 Jun 2017 22:54:43 +0000
Received: from ([]) by ([]) with mapi id 15.01.1220.011; Mon, 26 Jun 2017 22:54:43 +0000
From: Santosh Esale <>
To: Benoit Claise <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Benoit Claise's No Objection on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)
Thread-Index: AQHS610QSLlaj4xCoU+SCybpdv9v8qI3UlCA
Date: Mon, 26 Jun 2017 22:54:43 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2487; 7:oGBYlziqbymJjywlaV7tfMXrM7YIAvz4jX0oOo5HXwQsNWRQ9AyHV8muHRsxi3KbbLwScVQIzbPGEt990FmAQW0rJ+6YJfn2o6IJSXobakKG7TByu3cqX2/kNe1hQHghSfE4E18CwZdyEFDADr9saA/BVFDmQGQ9/UPP3OrcJfxy9ze1ZYlcU1JrYFSwqCZMinnYmevv48eM+NcGKiDbqW6OTspiLTBEiWJ5ZJJB+ytUccS889TvG1f41HEN5CGu360MSEJXgRV1frWy9Xi35b4OpHluK9CkSBsCaGFI75rCAI5CwdtTNKpFLYrlNWebFXWewUHLzjLXJJYcZuJTOiFphJclL239NR0iEkuIEexfGnjRQF7NmqtfXmETRI0RSiZPOz85haWc+Bt9/6jJcquMh3FsGSFDmza9k4eehEAqL4lOChZ7lKa2b+WaUTX6N5UjMX1aPQYnLqBl5X97uHq9I2ZZK/cPF9V3aRzFlDziygNO4uLP5qi+zEPlxIxs9IuUUorCGdbjZFZ+q5ZyOjE6x8JEQgp7RN3mcCReWU8yNzmqaFymbOBMJD9YNANfC4bjlgBd94DYX0pcqXNpbC/I+b5IKspOGJwBbpeAETXviq/p2E/T/BmMPXpftHDt1ORwxDyQbB/yHluGJNJSfFQUM8uAy3hfI6+TWB16cF4egBmCVVG+JU1lrqR4PoCFFaeJBi83tqshN4SxeU2l65Cy5BX/SpEmYoemkcS/8LCTha2muPB6AzwYlQOYYDdXVBuQoex1Y9m8WgySsm189uJK/QtyZlkgQxlhFnkhS6M=
x-ms-office365-filtering-correlation-id: 0f72574a-d0b2-4304-2bc6-08d4bce655c0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:CO2PR05MB2487;
x-ms-traffictypediagnostic: CO2PR05MB2487:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(278428928389397)(120809045254105)(236129657087228)(148574349560750)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2487; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2487;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39860400002)(39840400002)(39400400002)(39410400002)(51914003)(377454003)(24454002)(5660300001)(53546010)(6486002)(77096006)(3280700002)(4326008)(3660700001)(189998001)(2906002)(86362001)(6506006)(478600001)(76176999)(54356999)(2950100002)(230783001)(966005)(66066001)(25786009)(8936002)(122556002)(3846002)(102836003)(6116002)(54906002)(6436002)(14454004)(6512007)(99286003)(7736002)(229853002)(8676002)(305945005)(2900100001)(53936002)(6246003)(36756003)(38730400002)(50986999)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2487;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 22:54:43.2146 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2487
Archived-At: <>
Subject: Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jun 2017 22:54:47 -0000

Benoit, Please see inline for answers.
On 6/22/17, 6:40 AM, "Benoit Claise" <> wrote:

>Benoit Claise has entered the following ballot position for
>draft-ietf-mpls-app-aware-tldp-08: No Objection
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>Please refer to
>for more information about IESG DISCUSS and COMMENT positions.
>The document, along with other ballot positions, can be found here:
>Close to a DISCUSS, but in the end a COMMENT, assuming I don't know enough
>about tLDP. Let's have a discussion regardless.
>   This document
>   defines a mechanism to advertise and negotiate Targeted Applications
>   Capability (TAC) during LDP session initialization.
>   This document proposes and describes a solution to advertise Targeted
>   Application Capability (TAC), consisting of a targeted application
>   list, during initialization of a tLDP session.
>   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:
>   At tLDP session establishment time, a LSR MAY include a new
>   capability TLV, TAC TLV, as an optional TLV in the LDP Initialization
>   message.
>Reading the doc., I've been wondering for many pages now. Do we speak
>negotation ... From the initiating LSR: these are the Targeted Application
>(Identifier(s)) for which I would like to initializate a tLDP
>        Answer from the responding LSR: yes, possible. No, not possible
>        Question: is the tLDP session established.
Answer: (a) yes, (b) no.

>>From the initiating LSR: from this list, tell me which Targeted
>(Identifiers) you support
>        Answer from the responding LSR: here are the Targeted Application
>        (Identifiers) I support
>>From the receiving LSR: here are the Targeted Application (Identifiers) I
>Throughout the doc, clarify if the LSR is the initiating or receiving
>As a starting point, this text should be updated:
>       At tLDP session establishment time, a LSR MAY include a new
>       capability TLV, TAC TLV, as an optional TLV in the LDP
>       message.
>LSR => initiating LSR.
>Oh, wait, then I've been confused with: "If both the peers advertise TAC
>So both can start the negotiation?
No. The below example that immediately follows the above text clarifies
"For example, an initiating LSR advertises A, B and C as TA-Ids.
   Further, suppose the responding LSR advertises C, D and E as TA-Ids.
   Than the negotiated TA-Id, as per both the LSRs is C."
>Then you speak about "the responding LSR playing the active role in LDP
>So it's not about initiating/responding LSR any longer.
>A small diagram with arrows, at least for the most common case, would go
>a long

The earlier example describes the negotiation from initiating and
LSR's perspective. During LDP session initialization time, if the
initialing LSR 
also plays active role, the same text applies. However if it plays a
passive role, 
then first responding LSR advertises C, D and E as TA-Ids in a
message. After the receipt of that message, the initiating LSR advertises
A, B and 
C as TA-Ids. The negotiated TA-Id as per both the LSRs is again C - no

Thus, the first 3 paragraphs in section 2.2 introduce a general mechanism
the next four paragraphs describe the same mechanism based on who -
responding or 
initiating LSR - plays the active role in LDP session establishment.

I will also add a reference to section 2.5.4 of RFC 5036 which describes
initialization state machine with a diagram.

Thanks for the review !

Santosh (on behalf of Authors)