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

[Santosh Esale <[e-mail]>]

Hi Tarek,
        Thank you for the review and comments.

Please find some responses inline.
On 12/8/14, 10:14 PM, "Tarek Saad (tsaad)" <[e-mail]> wrote:

>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.
Section 5 describes interworking of this draft with
draft-ietf-mpls-ldp-ip-pw-capability. We have added more explicit
text to this section in version 03, which will be published shortly.


>For example, when conflicting
>TAC/SAC are used and how it can be interpreted?
Section 5, paragraph 4 and 5 describe the procedural preferences for
the co-existence of TAC/SAC and for the avoidance of conflicting
SAC/TAC on the tLDP session. Added ‘must’ keyword for these procedures.
   
>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?)?
The application type defined in draft-ietf-mpls-ldp-ip-pw-capability maps
to
LDP FEC type while the TA-Id defined here is tLDP application Id, which
is necessary to control tLDP session establishment per application and to
advertise only necessary LDP FEC-Label bindings for that application.

>
>- 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.
We will make it explicit in the new revision -03.

>
>* (Targeted Application Identifier (TA-Id)): would recommend making E-bit
>be at position 0 to be consistent with other definitions.
Thanks for the suggestion, We will change it.

>Section 3: 
>* it MUST teard down -> it MUST tear down
>* withdral -> withdrawal
Done.

>* repeated TA-Ids/TAEs on receive may be considered malformed (?) to be
>consitent with procedures in draft-ietf-mpls-ldp-ip-pw-capability?
We thought over it and arrived at a conclusion to ignore duplicates
rather then to consider them as malformed to avoid tLDP session flap.

>* 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.²
If the receiving LSR does not accept asymmetric tLDP hellos, asymmetric
tLDP sessions cannot be established to that LSR. So automatic applications
such as Remote LFA, BGP auto-discovered pseudowire, mLDP node protection
etc may not work.

>
>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?
It is ignored. Added in the new version.

>* can be more elaborative on handling TAC update in LDP capability
>message..
Okie.

>* s/disbaled/disabled
>* s/udpates/updates
Done.

>* "The LSR MAY add a different KeepAlive Time², why? not clear how
>related?
Removed.

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

Thanks,
Santosh
>
>
>On 2014-11-24, 2:40 AM, "Loa Andersson" <[e-mail]> wrote:
>
>>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: [e-mail]
>>Senior MPLS Expert                          [e-mail]
>>Huawei Technologies (consultant)     phone: [phone]
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls