Subject: Re: [mpls] MPLS-RT review of draft-esale-mpls-app-aware-tldp

From: <[email-masked]>
Date: Mon, 8 Dec 2014 18:05:15 +0100

Hi,

I was asked to perform a review of your individual internet draft draft-esale-mpls-app-aware-tldp. I have reviewed version -02 of your draft.

The document expresses the demand to signal the application capabilities of a targeted LDP (tLDP) session in the session setup phase and in a session re-negotiation phase. It specifies the encoding and the procedures applicable for tLDP sessions to negotiate the targeted application capabilities (TAC). The applications are the "purpose" of the label binding (e.g. LDPv4 or v6 tunneling, Remote LFA or FEC128/129 PW).

The proposed procedures satisfy available security and operational concerns, that LDP peers have to setup a tLDP session without the knowledge about its application (by configuration). Its implementation is useful (and required) in operational networks, especially in tLDP deployments without complete configured tLDP on both ends. We have had the same problem in our network.
The document describes the backward compatible behavior with LSR without the support of the procedures specified.

I think the document is coherent and ready to be adopted by the WG. It describes the need (section 1) and its implementation (section 2 to 6) and explains some use cases (section 7).

I have some minor editorial comments, which I will send in a separate mail.

Regards
Thomas 

-----Ursprüngliche Nachricht-----
Von: Loa Andersson [mailto:[email-masked]] 
Gesendet: Montag, 24. November 2014 08:40
An: [email-masked]; Beckhaus, Thomas; Lizhong Jin
Cc: [email-masked]; [email-masked]; VIGOUREUX, MARTIN (MARTIN)
Betreff: MPLS-RT review of draft-esale-mpls-app-aware-tldp

Tarek, Thomas and Lizhong,

You have be selected as MPLS-RT reviewers for draft-esale-mpls-app- aware-tldp.

Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
*really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.

Are you able to review this draft by Dec 9, 2014? Please respond in a timely fashion.

Thanks, Loa
(as MPLS WG chair)
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Tue, 9 Dec 2014 06:14:59 +0000

Hi,

below is my MPLS-RT review:

- is the document coherent?
Yes, in general, but can benefit from another editorial round.

- is it useful?
Yes, being able to control T-LDP session establishment on-demand using new
targeted application capability TLV is useful.

- is it technically sound?
Yes, but can benefit from being more explicit on how it complements and
possibly co-exists with work defined in
draft-ietf-mpls-ldp-ip-pw-capability. For example, when conflicting
TAC/SAC are used and how it can be interpreted? Another (idea) is can do
without extra mappings for Targeted Application Element to State
Advertisement Control (SAC) Elements as defined in
draft-ietf-mpls-ldp-ip-pw-capability (can it be unified app-id instead?)?

- is it ready for WG adoption?
Yes, but recommend undergoing another round of cleanup/editing before.

===
Comments:

Section 2:
* Value of U/F-bits: suggest being explicit on the recommended values‹
e.g. The value of the U-bit for the TLV MUST be set to 1 so that a
receiver MUST silently ignore this TLV if unknown to it, and continue
processing the rest of the message. The value of F-bit MUST be set to 0,
so to not forward.

* (Targeted Application Identifier (TA-Id)): would recommend making E-bit
be at position 0 to be consistent with other definitions.

Section 3: 
* it MUST teard down -> it MUST tear down
* withdral -> withdrawal
* repeated TA-Ids/TAEs on receive may be considered malformed (?) to be
consitent with procedures in draft-ietf-mpls-ldp-ip-pw-capability?
* can elaborate on the new requirement below.. What are implications of
not accepting by default?
      "Also, currently the remote LSR accepts asymmetric extended Hellos by
   default or by appropriate configuration. With this document, it
   should accept by default in order to then accept or reject the tLDP
   session based on the application information.²

Section 4:
* s/an LSR MAY using/an LSR MAY use

Section 5:
* "The E-bit of the Targeted Application Element MUST be set to 1 to
enable Targeted application.². How to handle when E-bit is 0 on RX, is it
malformed, or ignored?
* can be more elaborative on handling TAC update in LDP capability
message..

* s/disbaled/disabled
* s/udpates/updates
* "The LSR MAY add a different KeepAlive Time², why? not clear how related?

Section 6:
* s/initialazation/initialization
* s/procceds/proceeds
* s/establishemt/establishment

Regards,
Tarek

On 2014-11-24, 2:40 AM, "Loa Andersson" <[email-masked]> wrote:

>Note to authors: You have been CC'd on this email so that you can know
>that this review is going on. However, please do not review your own
>document.
>
>Reviews should comment on whether the document is coherent, is it
>useful (ie, is it likely to be actually useful in operational
>networks), and is the document technically sound?  We are interested
>in knowing whether the document is ready to be considered for WG
>adoption (ie, it doesn't have to be perfect at this point, but should be
>a good start).
>
>Reviews should be sent to the document authors, WG co-chairs and
>WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
>may be sent privately to only the WG chairs.
>
>*really* need to be resolved before adopting it as a working group
>document, and what can wait until the document is a working group
>document and the working group has the revision control.
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Tue, 9 Dec 2014 16:13:37 +0800

Forget to cc to the WG list, sorry.

Lizhong

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]] 
Sent: 2014年12月9日 15:58
To: 'Loa Andersson'; [email-masked]'; [email-masked]'
Cc: [email-masked]';
[email-masked]'; 'VIGOUREUX, MARTIN (MARTIN)'
Subject: RE: MPLS-RT review of draft-esale-mpls-app-aware-tldp

Hi authors,
I review the document, and it is technically sound and useful, and ready for
adoption. Some minor comments are as below.
Section 3, "On the receipt of a valid TAC TLV...". You do not say explicitly
how to handle the E bit, ignore?
Section 3, "If it sets the session setup retry interval to maximum, the
session MAY stay in a non-operational state". " non-operational " should be
" NON EXISTENT " according definition in RFC5036?
Section 3, have you consider the overflow of Configuration Sequence Number?
I did not see that in RFC5036.
Section 4, it seems there is still some application missed, e.g., Entropy
Label Capability, HSMP LSP Capability, etc.

Regards
Lizhong

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 2014年11月24日 15:40
> To: [email-masked]; [email-masked]; Lizhong Jin
> Cc: [email-masked]; mpls- 
> [email-masked]; VIGOUREUX, MARTIN (MARTIN)
> Subject: MPLS-RT review of draft-esale-mpls-app-aware-tldp
> 
document.
> adoption (ie, it doesn't have to be perfect at this point, but should be a
good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and WG 
> secretary, and CC'd to the MPLS WG email list. If necessary, comments