Subject: Re: [mpls] Quick review for - http://tools.ietf.org/html/draft-esale-mpls-appl-aware-ldp-targeted-session-00

From: Santosh Esale <[email-masked]>
Date: Thu, 14 Aug 2014 23:51:01 +0000

Hello Uma,
         Thanks for the review. Please see my comments inline.

On 7/26/14, 9:24 AM, "Uma Chunduri" <[email-masked]> wrote:
>Hi Santosh,
> 
>Just gone through the document and some quick review comments.
>It’s a good document and generalizes SAC and gives more control at
>receiving LSR.
> 
>===
> 
>1. Section 1
>   "In these applications, the remote LSR is not
>   explicitly configured with the source LSR address, so the remote LSR
>   either responds to all LDP requests or ignores all LDP requests."
> 
>   There is some configuration needed on remote LSR to accept on the fly
>session from incoming LSRs.
>
>   So this is implementation specific.
>   So the statement "not explicitly configured" is partially correct.
>Need to improve the language here perhaps.
Yes, We will re-phrase it in the next version.

> 
>2. Section 1 - "Also, the receiver LSR does not know whether the
>   source LSR is establishing the session for a configured or an
>   automatic application."
> 
>   This is one of the most critical piece of the document, apart from
>advertising avoiding unnecessary FECs!
> 
>3. Section 2:
>   Please add 5561 reference one more time (to see what are those for)
>just before U/F/S bits description for TAC.
Okie.

> 
>4. Section 3:
>   "The TAC TLV's
>      Capability data MUST consists of none, one or more Targeted
>      Application Element(TAE) each pertaining to a unique Targeted
>      Application Identifier(TA-Id)."
> 
>    Why NONE? 
Consider a sender LSR that wants to establish a automatic targeted
session to the receiver LSR for Remote LFA. Further, suppose the sender
and receiver LSR plays passive and active roles respectively in LDP
session establishment. Also, assume the receiver LSR’s administrative
policy or certain configured automatic session limits rejects this
session. So a receiver LSR that plays active role in LDP session
establishment may send a initialization message with TAC TLV consisting
of no TAE elements. After receipt of this initialization message, a
sender LSR determines that a automatic targeted session for remote LFA
cannot be established. So, it sends a 'Session Rejected/Targeted
Application Capability Mis-Match’ notification message to the receiver
LSR. Also, It may destroy the targeted adjacency that it has established
with the receiver LSR. It may also inform the local IGPs to choose a
different PQ node for a set of routes.

> 
>5. Section 3
>   "If the receiver LSR receives the same
>      TA-Id in more than one TAE element, it MUST discard the TAC TLV and
>      behave as if TAC TLV is not received. If the receiver LSR receives
>an
>      unknown TA-Id in a TAE element, it SHOULD silently ignore such a TAE
>      element and continue processing the rest of the TLV."
> 
>   Also it's better to indicate sender MUST not send more than one same
>TA-Is/TAE. Also consider SHOULD ==> MUST in    the
>later sentence, as it's critical for future TAE extensibility.
Agree. Kamran has also suggested a change here. We will address both
the comments.

> 
>6. Section 3.
>   "Similarly, a LSR MUST request
>      FEC label bindings for the negotiated applications only."
>    I didn't understand this statement. How this happens through TAC?
This text refers to downstream-on-demand mode label request.
We will clarify it.

> 
>7. Section 5
>    - You can put a reference to Section 3
Okie.

> 
> 
>8. Section 7
>    - To make sure for backward compatibility, it's better to put a
>statement to indicate
>if the receiving LSR doesn't
>
>
>understand TAC TLV it can ignore and there is no change in existing
>procedures. My worry is the selected PQ node from
>
>
>IGP/or FEC129/etc, which can't process TAC TLV must continue to what it
>is doing today.
Sure. We will add more text.

Santosh