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

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jun 2017 06:40:05 -0700

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

>From the initiating LSR: from this list, tell me which Targeted Application
(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
support

Throughout the doc, clarify if the LSR is the initiating or receiving party.
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 Initialization
       message.

LSR => initiating LSR.

Oh, wait, then I've been confused with: "If both the peers advertise TAC TLV,"
So both can start the negotiation?

Then you speak about "the responding LSR playing the active role in LDP session"
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
way.

---

From: Santosh Esale <[email-masked]>
Date: Mon, 26 Jun 2017 22:54:43 +0000

Benoit, Please see inline for answers.

>https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/
Answer: (a) yes, (b) no.

>So both can start the negotiation?
No. The below example that immediately follows the above text clarifies
it. 
"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."
>A small diagram with arrows, at least for the most common case, would go

The earlier example describes the negotiation from initiating and
responding 
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
initialization 
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
change. 

Thus, the first 3 paragraphs in section 2.2 introduce a general mechanism
while 
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
LDP 
initialization state machine with a diagram.

Thanks for the review !

Santosh (on behalf of Authors)