Subject: [mpls] Comments on draft-esale-mpls-appl-aware-ldp-targeted-session-00

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Fri, 1 Aug 2014 16:49:04 +0000

Hello Santosh/authors,

Refer to our chat during IETF90, I have few comments, observations, and
questions on this new I.D.

General
=======
- This I.D states the App-aware-TLDP as a solution to following two
problem statements:
   (a) Control acceptance of TLDP session for asymmetric config cases
(like rLFA)
   (b) Advertise only necessary FEC bindings over a session

  Ref (a): It is bit misleading as the document is NOT addressing the
issue of acceptance of
     TLDP Hellos for such asymmetric cases; Instead, it is trying to just
control the
     session establishment/progress (for resource control/limit reasons
etc) and seems to assume that
     T-hello acceptance is already handled (e.g. Via passive side accept
config etc).
     If this is the case, then document should state this assumption
explicitly.

     On the same topic, I think that it would serve better if this TLDP
capability was sent
    in a Hellos rather than post-session; This way you could even control
formation of 
    unnecessary tgt-adj + avoid overhead of session estab (and teardown of
non-acceptable sessions)

  Ref (b): This is trying to solve a problem which has already being
addressed
     in other existing drafts (ip-pw-capability, ldp-ipv6) etc. The scope
of this I.D., however,
     is just TLDP sessions when compared to earlier I.D + It adds TLDP-app
knowledge to peers.
     This I.D. has some intersections with the other I.Ds and need careful
analysis of interworking.

Section 2
=========
  - Can this Tgt-App Capability (TAC) advertised only on a TLDP session ?
What are procedures if
    it is rxd on a non-tldp session ? What are procedures if a session
type changes from
    tldp -> non-tldp and vice versa.

 - Regarding Targeted-Application Identifiers (TA-Id):
     (i) The ID is missing ICCP and Session Protection applications from
the list.
     (ii) The ID is also missing P2MP PW FEC 130 (in case p2mp-pw I.D.
Still progresses)
     (iii) For an LSR which has NONE of the listed applications configured
but can still establish/permit
       A tLDP session (e.g. as a pure passive LSR accepting T-Hellos),
there should be a TA-ID to cover such case.
       I suggest ³Passive² as the type.

 - Since TAC is a list of the Apps, the I.D. Needs to clarify how is an
update constructed/decoded ?
   i.e. if an App changes, whether the update is just incremental or a
snap-shot of all negotiated apps ?

Section 3
=========
  - Is TAE is an indicative of a ³supported² or ³cfged² type ? I read it
as ³cfged². 
    The document is bit fuzzy about this important detail and needs some
elaboration.

  - re: "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.².
    Q: Why not just process the 1st such element and ignore all
duplicates/conflicting one.
    Why are we penalizing the entire TLV ?
 
  - re: "On the receipt of a valid TAC TLV, an LSR MUST generate its own
TAC TLV².
    I am not sure this is doable at INIT time though; I.e. An LSR  should
generate its own TAC TLV without
    depending on receipt from other LSR.
 
  - re: "The sender LSR playing the passive role in LDP session
establishment MAY destroy the corresponding targeted adjacency.²
    Q: Did you not mean to say ³destroy the corresponding session² ?

  - re: "When it detects a change in the sender LSR configuration or local
configuration pertaining to TAC TLV..²
   Q: How does an LSR detect change in sender LSR configuration ? If this
is through Cfg Seq No, then ID needs to explictly
      state so.

   - re: "After an LDP session has been established with TAC capability,
the sender and receiver LSR MUST distribute
          FEC label bindings for the negotiated applications only.²
    I suggest to add a section mapping your TA-types to FEC-types. Note
there could be multiple TA associated with the
    same FEC type (example: LDP tunneling, rLFA)

   - re: "This MAY lead to advertisements or withdrawals of certain FEC
types²
   I suggest use ³This may lead to Š."

Section 4: SAC and TAC capability interworking
==========
   - re: "The TAC mechanism takes precedence over the SAC mechanism with
respect to enabling
     applications for which state information will be advertised.²

    I am not sure I agree (as a SAC author). Note that SAC scope for IP/PW
capability is wider than
    TAC as it applies to both TLDP and non-TLDP. We will need to discuss
more and close later.

Section 5.1
===========
   - Could you elaborate more on different holdtime value for an automatic
tgt session ? 
   
Section 5.2
===========
   - Seems like this TAC capability can NOT be withdrawn (as S-bit is
always set to 1). 
     I understand that you control your withdrawal of T-App by ³E² bit but
I still think 
    That there is a value in allowing S=0 (with no TAC elements) in the
TLV - which could indicate
     wildcard disaable for all such T-Apps.

Section 7.3
===========
   - Use case LDPoTE + rLFA session: Not sure practicality of this use
case because if u have TE tunnel terminating on remote [PQ] node,
    that node typically becomes your local LFA peer and not a remote/PQ
LFA peer.

Section 9: IANA
=========
  - The new registry for TA-type has range of 0-65535 though TA-ID that
can be specified in the signaling is
   Only 8 bits. Should the range for this type not be 0-255.

Rgds,
‹
Kamran Raza
[email-masked]
Phone: +1 613 254 4520
Cisco.com <http://www.cisco.com/>

---

From: Santosh Esale <[email-masked]>
Date: Mon, 11 Aug 2014 19:20:23 +0000

Hi Kamran,
          Thanks for the detail review. Please see inline
for some answers.

>     If this is the case, then document should state this assumption
The asymmetric TLDP hellos are accepted by simple On/Off control on
the receiver LSR. Currently, it is a implementation choice to have it
On or Off as a default behavior. Some implementations choose to do
the former while few others do the later. With this draft, it should
be On by default. If you feel that it needs to be spelled out explicitly,
i am fine with it.

>    unnecessary tgt-adj + avoid overhead of session estab (and teardown of
Couple of reasons to negotiate Targeted application capability on
a TLDP TCP session and not UDP Hellos -
(1) Hellos are less secured.
(2) Every Hello message needs to carry the TAC capability TLV, which is
unnecessary.

The new procedures are used during session initialization. If the TAC
negotiation fails during initialization, the session is not formed and
the corresponding targeted adjacency may be destroyed. If the TAC
negotiations fails after session establishment with the receipt of a
capability message, the session is teardown and the corresponding
targeted adjacency may be destroyed.

>analysis of interworking.
The I.D conveys the application information to the receiver LSR
and uses it to advertise the necessary FECs. Interworking details
with ip-pw-capability are described in section 4.

>    tldp -> non-tldp and vice versa.
The Targeted App capability is advertised on TLDP session only.
The LSR should silently ignore it on link session. The LSR should
use dynamic capability and capability message to negotiate the
Targeted App capability when the session type changes from non-tldp
to tldp. We will clarify it in next version.

>       I suggest ³Passive² as the type.
(i) (ii) thanks. We will include them in the next revision.
(iii) A LSR should form the list of applications ids that it can
      support over the session. If the suggestion is to add a passive
      bit to the TAE element to indicate that the LSR is not configured
      for it, we will think this through and get back.

>snap-shot of all negotiated apps ?
 It is just incremental.

>    The document is bit fuzzy about this important detail and needs some
The TAE indicates that a LSR supports the specific application over
The TLDP session. For instance, use case 7.1. We would clarify it.
  
>    Why are we penalizing the entire TLV ?
Good suggestion. We will change it in the next revision.

>    depending on receipt from other LSR.
A LSR has to update its own TAC TLV based on the configuration and number
of already established sessions for different applications. For instance,
If the last session established was 100th Remote LFA session and if the
LSR is configured to accept 100 such sessions, it has to generate/update
its TAC TLV without Remote LFA application so that it does not accept the
101th remote LFA session. Either it can generate the TAC TLV after the
establishment of last session or during acceptance/initialization of a
new session. We have chosen the later, but i am okie with former too.

>    Q: Did you not mean to say ³destroy the corresponding session² ?
No. Suppose the sender LSR has initiated a asymmetric targeted discovery
to the receiver LSR. Further, suppose the sender LSR is playing a passive
role in LDP session establishment. After the receipt of initialization
message with a TAC TLV from a receiver LSR, if the sender LSR does not
find the app-id that it intends to establish the session for, it will
send A 'Session Rejected/Targeted Application Capability Mis-Match’
Notification Message. Also, it may decide to destroy the corresponding
targeted adjacency that it has initiated.

>is through Cfg Seq No, then ID needs to explictly
Okie. We will state it explicitly.

>    same FEC type (example: LDP tunneling, rLFA)
Section 4 covers it.

>   I suggest use ³This may lead to Š."
Okie.

>Section 4: SAC and TAC capability interworking
We have described the intersection between the two drafts. Sure, We can
discuss and close on it.

>Section 5.1
Currently, some implementation allows a common holdtime value for all
TLDP sessions. The intention is to state that the automatic targeted
sessions are different. So, if needed, a TLDP holdtime value can be
different for such a session.

>Section 5.2
All the T-Apps are disabled by listening each of them individually with
E-bit off. If you think it is good to provide a wildcard T-Apps
withdrawal, sure.

>Section 7.3
User can prefer Remote LFA over LFA or vice versa based on configuration.

>   Only 8 bits. Should the range for this type not be 0-255.
We will change it.

Thanks,
Santosh