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

["Tarek Saad (tsaad)" <[e-mail]>]

Thanks Santosh. I am OK with the revised changes.

Regards,
Tarek

On 2015-01-06, 7:59 PM, "Santosh Esale" <[e-mail]> wrote:

>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
>
>