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

Santosh Esale <> Mon, 26 June 2017 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 511E8129B19; Mon, 26 Jun 2017 14:27:21 -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 Y2UOjsZa2RXP; Mon, 26 Jun 2017 14:27:18 -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 51521129B02; Mon, 26 Jun 2017 14:27:18 -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=UEDC+PjA7RjSDvzOAdCmwAEh4KOWNwGHNrnYNBwatlg=; b=eWZLQLkEWg5PqeHoL5P4LIhujtzVJIbPS7HOoFUhwbj/jMQe7zh2JsuEGVmk/OxFO6iXRyqSZBkMQCcLhySnZJquT0M9WNV+Arhk9PPmRfuRJKjShlxUsiSzACgaUIehzTwoeBL2abhG1xcHCJGq53YsMdUhGH8xla6LW0osK6o=
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 21:27:16 +0000
Received: from ([]) by ([]) with mapi id 15.01.1220.011; Mon, 26 Jun 2017 21:27:16 +0000
From: Santosh Esale <>
To: Eric Rescorla <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)
Thread-Index: AQHS6s7fl2sdRZGXYkOMx00d0kqwLqI3Ov4A
Date: Mon, 26 Jun 2017 21:27:16 +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; CO2PR05MB2629; 7:+MLBtd0eARhpbnx8HYsiNSStk+sbhOVjdrCQrc83h/mixW/UkGwfbyVhgOoHLN1/ehWqMKC3xJIbi52Hlmse/R27oSEz4AdRCidXMEG0yDKhBITsLLlxAxBI669HJkV4OnyZ7gNa6QC2JQq8pGZq86NvO8L0Eol8yCOEWjErIVGGOKwjGHJRGrr68wPrnuhqte4Uyxr718mc8IrHVuxtCF3rl07p8QQA/rHcIMFvS1FPfeq42eHXVEjRn3CqpTrWDdu7e1sw23TLPzulir4kpaKTj6Iigz5a5KbhxHYZy5+OEYOkS+IqwQrjD9EOvOcliR+Jnr3vItDnYc/+0ZkhoUh/aZ3cmDl0cVrJv0BJE4IcKPq9Sq4OKtGrysYs2cXzThYXqrC3eef1wKrhXSGGVHunW0IwbUfPYumJgkW08b+s3IOi9WSEDWOTkSOpcH9wjoeASm7TnGMo37WNmFDOJ+oSZ5S0hC/s/cU8E7OL9GSqqdTR9JAVq2OGbHEUa2eqaG4tGVnH2gczRzP4KM4aB0bQ0Zs2XI/si6Ee3sE73oAzldia2HDkvl1EjIJpJQtsdZ8jRUJHopfacWKa7kzyd3lz33HcRCu3uJDhi/EFq3L/acabI2p2BSxqOOuXzeJId/HzmxweS8c/27R3Aeo6MQp4XwDnRHEUx/lvSIhNkg43Rh4bOM264s1dLqCn24nbbjw4PpzTYbPBkdafVHqkEvvu7jXsyVDArZvux/IPMtLLvc9YuoLY0hMiBerl+Z2sA5KjaQ2RIEWyPLz66GkcZzh8BcKpVzK506HVaxcQMc0=
x-ms-office365-filtering-correlation-id: ad915e39-1608-43d7-5266-08d4bcda1e99
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:CO2PR05MB2629;
x-ms-traffictypediagnostic: CO2PR05MB2629:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(278428928389397)(120809045254105)(236129657087228)(148574349560750)(167848164394848)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2629; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2629;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39860400002)(39410400002)(39450400003)(39850400002)(51914003)(24454002)(377454003)(2950100002)(6246003)(99286003)(6486002)(6512007)(38730400002)(50986999)(6306002)(53936002)(77096006)(3846002)(3660700001)(189998001)(230783001)(54906002)(122556002)(6116002)(102836003)(2906002)(36756003)(4001350100001)(54356999)(76176999)(229853002)(53546010)(14454004)(6436002)(3280700002)(8676002)(25786009)(66066001)(5660300001)(966005)(305945005)(6506006)(8936002)(7736002)(4326008)(86362001)(81166006)(478600001)(83506001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2629;; 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 21:27:16.7089 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2629
Archived-At: <>
Subject: Re: [mpls] Eric Rescorla'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 21:27:21 -0000

Hello Eric,
          Please see answers inline.

On 6/21/17, 1:42 PM, "Eric Rescorla" <> wrote:

>Eric Rescorla 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:
>Document: draft-ietf-mpls-app-aware-tldp-00.txt
>   LDP can use the extended discovery mechanism to establish a tLDP
>   adjacency and subsequent session as described in [RFC5036]. An LSR
>Please expand LDP and tLDP on first use. Also, I don't see tLDP in
>RFC 5037 despite the citation

Expanded. The citation is for extended discover mechanism.
>S 2.1.
>       A Targeted Applications Capability data consists of none, one
>       or more 32 bit Targeted Application Elements. Its encoding is
>       as follows:
>This is ungrammatical. Is it intended to say "zero or more"?

That’s the intention. Updated.

>S 2.2.
>   If the receiver LSR does not receive the TAC 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]. On the receipt of a valid TAC TLV, an LSR
>   MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids
>   that it supports over the tLDP session. 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]. If not, A LSR MUST
>   send a 'Session Rejected/Targeted Application Capability Mis-Match'
>   Notification message to the peer and close the session. The
>   initiating LSR SHOULD tear down the corresponding tLDP adjacency
>   after send or receipt of a 'Session Rejected/Targeted Application
>   Capability Mis-Match' Notification message to or from the responding
>   LSR respectively.
>This seems like odd semantic: if I don't understand the TLV, I continue
>with session establishment, but if I understand it but there's no overlap
>I close the session?

It is for backward compatibility. The LSR running the older code that
does not support these extensions should not close the session.
>   instance, suppose a 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. In the second
>   instance, suppose a initiating LSR advertises A, B and C as TA-Ids
>   and the responding LSR, which acts as a passive LSR, advertises all
>   the applications - A, B, C, D and E that it supports over this
>   session. Than the negotiated targeted application as per both the
>Should this say "applications"?

Yes. The latest - 08 version - has this change.

>It seems like you're just computing

>   If the Targeted Application Capability and Dynamic Capability, as
>   described in [RFC5561], are negotiated during session initialization,
>   TAC MAY be re-negotiated after session establishment by sending an
>   updated TAC TLV in LDP Capability message. The updated TAC TLV
>   carries TA-Ids with incremental update only. The updated TLV MUST
>   consist of one or more TAEs with E-bit set or E-bit off to advertise
>   or withdraw the new and old application respectively. This may lead
>   to advertisements or withdrawals of certain types of FEC-Label
>   bindings over the session or tear down of the tLDP adjacency and
>   subsequently the session.
>So, advertisements are cumulative? If I advertise A, B and then C,
>that means I do A, B, C?

Thanks for the review !

Santosh (On behalf of Authors)