Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 6 Aug 2014 19:01:30 +0000

Kamran, Sami,

Lots of thanks for your cooperation.

I believe that we have successfully resolved all the remaining issues at our WebEx call today.

I will be waiting for the next revision of the draft to formally confirm that.

Adrian and all,

It took more time than we originally planned - but we did it!

Regards,

Sasha

________________________________
From: Kamran Raza (skraza) <[email-masked]>
Sent: Wednesday, August 6, 2014 8:56 PM
To: [email-masked]
Cc: [email-masked]; Sami Boutros (sboutros); [email-masked]; Alexander Vainshtein; [email-masked]
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

Hi Adrian,

We (authors) just had a webex call with Sasha to discuss/close on his comments [ which we had also discussed over the email starting May ].
We all are in agreement/sync on the points that were raised during this review . Almost all, if not all,  of the points/comments will be addressed by
clarifying the  scope of the extension in a new “Applicability" section with risk and recommendations highlighted.

We will work on updating the draft and post a new rev shortly.

We thank you Sasha for his detailed review and useful comments and thank you for your patience.
—
Kamran and Sami

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 30, 2014 at 6:16 PM
To: Syed Kamran Raza <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Sami Boutros (sboutros)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Alexander Vainshtein' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

This is very excellent. Thank you for going the extra mile to sort things out.

A

From: Kamran Raza (skraza) [mailto:[email-masked]]
Sent: 30 July 2014 19:00
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Sami Boutros (sboutros); [email-masked]<mailto:[email-masked]>; 'Alexander Vainshtein'; [email-masked]<mailto:[email-masked]>
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

Hi Adrian,

Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to schedule the meeting post IETF as Sasha did not attend.
We are meeting tomorrow with Sasha to clarify/converge.

Thanks.

Kamran Raza
TECHNICAL LEADER.ENGINEERING
Product Development
[email-masked]<mailto:[email-masked]>
Phone: +1 613 254 4520

Cisco.com<http://www.cisco.com/>

Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Phone: 416-306-7000; Fax: 416-306-7099.
Preferences<http://www.cisco.com/offer/subscribe/?sid=000478326> - Unsubscribe<http://www.cisco.com/offer/unsubscribe/?sid=000478327> – Privacy<http://www.cisco.com/web/siteassets/legal/privacy.html>

[Image removed by sender.] Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran Raza <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Sami Boutros (sboutros)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Alexander Vainshtein' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

Kamran,

Thanks for responding to the question in the GenArt review.

Do you have any responses to Sasha's review (copied below)?

cheers,
Adrian

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: 11 May 2014 15:09
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Sami Boutros ([email-masked]<mailto:[email-masked]>)
Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft.

The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs.

For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

Reviewer: Alexander (“Sasha”) Vainshtein

Review date: 11-May-14

IETF LC End Date: 12-May-14

Intended status: Standards Track

Summary:

I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

These concerns mainly deal with potential negative impact of the mechanisms (introduced in the draft) for disabling “non-negotiable” capabilities of LDP sessions  with the techniques that could dynamically change the state of “interest” in these capabilities for a given LDP session.

Some of these mechanisms are already standardized by the IETF, e.g.,   L2VPN auto-discovery (RFC 6074<http://tools.ietf.org/html/rfc6074>) and  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw<http://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw/?include_text=1>) while others -  LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/?include_text=1>)- are in advanced stages of the IETF process.

I must admit that I did not follow closely the discussion of  the draft in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found not relevant.

I also do not know if the draft has ever been discussed in the PWE3, L2VPN and RTG WGs.

One possible way to address these concerns would be by adding an Applicability Statement section to the draft and discussing potentially problematic combinations of mechanisms there.

I have discussed this option with the authors and, to the best of my understanding, they have in general agreed to add such a section to the next revision of the draft.

General comments:
To the best of my understanding the sole purpose of the draft is  prevention of “ wasteful” distribution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC 5036<http://tools.ietf.org/html/rfc5036>) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447<http://tools.ietf.org/html/rfc4447>) to LDP peers that are “not interested’ in this state. Such unnecessary distribution would result in unnecessary waste of resources (memory and/or CPU cycles) and hence should be avoided.

The draft mentions that:
<quote>
  To avoid this unnecessary state advertisement and exchange, currently
  an operator is typically required to configure and define filtering
  policies on the LSR, which introduces unnecessary operational
  overhead and complexity for such deployments.
<end quote>

The draft, however, does not mention that filtering policies provide much finer granularity of control over distribution of labels than that supported by the mechanism introduced in the draft.
E.g., in a scenario when LDP is supposed to set up only “tunnel LSPs” between PEs for L2 and L3 VPN applications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FECs associated with the subnets of their core-facing interfaces. IMHO and FWIW this means that support of the mechanism defined in the draft would not eliminate the need for the filtering policies.

I have discussed this point with the authors and they have agreed to add some clarifying text.

I have also failed to understand how distribution of PW FECs could be wasteful. Section 5.3.3  “Signaling Procedures” of RFC 4447<http://tools.ietf.org/html/rfc4447> explicitly states that:
<quote>

   In order for PE1 to begin signaling PE2, PE1 must know the address of

   the remote PE2, and a TAI.  This information may have been configured

   at PE1, or it may have been learned dynamically via some

   autodiscovery procedure.

   The egress PE (PE1), which has knowledge of the ingress PE, initiates

   the setup by sending a Label Mapping Message to the ingress PE (PE2).
<end quote>

My reading of the quoted text is that PW FECs are only distributed across targeted LDP sessions with the known Remote PEs for specific PWs.
AFAIK, this is what actually happens in most existing implementations of PW signaling with RFC 4447.
What’s more, many implementations, when required to set up a PW with a specific remote PE, check for existence of a targeted LDP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC-to-label binding via this session only. Implicit targeted LDP sessions are also implicitly torn down when the last PW between  the given pair of PEs is torn down.
I have discussed this point with the authors, but, as of the moment of writing this review,  we did not yet reach full agreement on it.

Readability of the draft:

Initially I have failed to understand the following text fragment in the draft (the problematic statements are marked with italics):
<quote>

   For Prefix-LSPs application type, the non-interesting state refers

   to any state related to IP Prefix FEC (such as FEC label bindings,

   LDP Status). This document, however, does not classify IP address

   bindings as a non-interesting state and allows the advertisement of

   IP Address bindings to facilitate other LDP applications (such as

   mLDP) that depend on learning of peer addresses over an LDP session

   for their correct operation.
<end quote>
After discussing this point with the authors I’ve understood that they refer to exchange of the LSR addresses in the Address and Address Withdraw messages that is required for mapping Next Hop IP addresses computed by the IGP to Next Hop LSR. While initial misunderstanding may be specific to me,  I have suggested to the authors to clarify this point with explicit references to specific LDP messages and sections of RFC 5036<http://tools.ietf.org/html/rfc5036>.

Major Issue:

The draft, which builds on the mechanisms defined in RFC 5561<https://datatracker.ietf.org/doc/rfc5561/?include_text=1>,  defines two ways to manipulate distribution of “non-interesting state”, since by default it would be enabled

·         In the Initialization message. I assume that in this case the only valid use case would be disabling distribution of non-interesting state

·         In the Capability message. This method could be both to disable and re-enable distribution of state, but it could only be used if the peer supports “Dynamic Announcement Capability”.

My concern stems from the fact that the draft deals with “old” LDP applications, so that the possibility that distribution of FEC-to-Label bindings can be unilaterally disabled for PW- and Prefix-FECs is not taken into account in the existing deployments and mechanisms.

Here is a couple of examples:

Consider the case when a targeted LDP session between PE1 and PE2 has been set just for the purpose of running ICCP between these devices (i.e., in the terms of the ICCP draft they belong to the same RG). According to the example in Section 5.1 of the draft, the PEs could then disable distribution of both PW FECs and Prefix-FECs across such a session in their appropriate Initialization messages.

The following (valid from my point of view) scenarios would make such a setting highly problematic:

1.       The operator that manages both PE1 and PE2:

a.       Maintains some  VPLS instances in its network

b.      Initially maintains VPLS instances in both E1 and PE2, but without overlap between the sets of these instances (so that there is no need to setup PWs between PE1 and PE2)

c.       Uses BGP-based autodiscovery mechanisms for VPLS in its network as described in RFC 6074

d.      Is required to extend one of the VPLS instances it maintains and that already has presence in PE1 to have presence also in PE2:

                                                                i.      With BGP-based autodiscovery, explicit configuration of just PE2 should suffice, the person (or management application) that extends this instance does not have to know about the rest of the locations where this VPLS instance is present

                                                               ii.      The autodiscovery process (which does not depend on LDP) identifies PE1 as a peer for the VPLS instance being defined in PE2, so that a PW between PE1 and PE2 is now required

                                                             iii.      The PW setup process finds a targeted LDP session between PE1 and PE2 and tries to use it for setting up the required PW

                                                             iv.      However, PW setup would fails because distribution of PW FECs across the already existing targeted LDP session between PE1 and PE2 has been disabled.

e.      If PE1 and PE2 support “Dynamic Capability Announcement”, this could be amended by enabling distribution of PW FECs prior to setting the required PW. However, this would require substantial changes in the existing PW setup procedures

f.        If even one of the PEs does not support “Dynamic Capability Announcement”, the existing targeted LDP session would have to be torn down and re-established again. This would probably have serious implications for the ICCP-based redundancy mechanism.

2.       A similar scenario could be encountered if the operator employs dynamic setup of multi-segment PWs, and the PW routing mechanism decides that one of the segments of a new MS-PW to be set up should run between PE1 and PE2.   Such a situation could be probably prevented if the PW routing mechanism could learn that PE1 and PE2 cannot be “directly connected”, but, to the best of my understanding, it would require changes in the already standardized MS-PW routing mechanism.

I have discussed these cases with the authors, but we have not reached an agreement on them yet. From my point of view, the Applicability Statement section should address these concerns.

Consider now the case described in Section 5.2 of the draft, when a targeted LDP session between PE1 and PE2 is initially used just for distribution of setup of PWs, so that distribution of Prefix-FECs is disabled.

The following (valid from my point of view) scenario would make such a setting highly problematic:

1.       The operator uses LDP for setting “Tunnel LSPs” in its network

2.       LFA-based LDP FRR (as per RFC 5286<https://datatracker.ietf.org/doc/rfc5286/?include_text=1> and Remote LFA draft<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/?include_text=1>) is used as the mechanism for fast protection in the operator’s network.

3.       Initially PE1 can protect all the LSPs passing through it using just local LFA.

4.       The network topology changes (e.g., because new LSRs are added to it), and in order to provide the required coverage, PE1 has to use PE2 as its “remote LFA” for some destinations.

a.       This would require distribution of Prefix-FECs across the targeted LDP session between PE1 and PE2 – but it has been disabled

b.      If PE2 does not support “Dynamic Announcement Capability”, then the only way to amend the situation would be to tear down the targeted LDP session between PE1 and PE2 and to set it up again – but this would negatively affect PW traffic between PE1 and PE2.

I have discussed this case with the authors. To the best of my understanding, they have agreed that combining LDP FRR based on Remote LFAs with the mechanisms defined in the draft would be highly problematic, and will add some suitable text to the Applicability Statement section in the next revision of the draft.

Minor Issues:

1.       The draft states (in section 4.2) that desire of a given LSR  of reception of unnecessary state from the peer is “unilateral and unidirectional by nature”.

a.       IMO this makes perfect sense for Prefix-FECs.

b.      However, PW FECs must always be exchange in both directions of  a targeted LDP session, so that disabling their distribution in just one direction would effectively prevent setup of PWs between the given pair of PEs

2.       I concur with Adrian’s comment in his AD review of the draft about proposed encoding of states of non-interest.

3.        I also wonder whence the need for 16 potential states of non-interest in the draft that, to the best of my understanding, deals with exactly 4 “old” LDP applications. I hope that this does not imply possibility of developing new “old-style’ LDP applications in future (or discovering some forgotten old ones?).

I have not yet discussed these issues with the authors (as we concentrated on the major ones).

Nits:
None found by the IDNITS tool.

Spelling and Grammar:
I defer to the English Language review team.

Hopefully these comments will be useful.

Regards,
       Sasha
Email: [email-masked]<mailto:[email-masked]>
Mobile: +972-54-9266302

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Wed, 6 Aug 2014 17:56:53 +0000

Hi Adrian,

A

Hi Adrian,

Thanks.

Kamran Raza

Kamran,

cheers,
Adrian

Hello,

Review date: 11-May-14

Summary:

General comments:

The draft mentions that:
<quote>

   autodiscovery procedure.

Major Issue:

Minor Issues:

Nits:

Spelling and Grammar:

Regards,
       Sasha

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Aug 2014 11:10:01 +0100

Very grateful for the time and effort you all put into resolving this.
 
Adrian
 
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 06 August 2014 20:02
To: Kamran Raza (skraza); Sami Boutros (sboutros)
Cc: [email-masked]; [email-masked];
[email-masked]; Adrian Farrel
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt
 
Kamran, Sami,
Lots of thanks for your cooperation.
I believe that we have successfully resolved all the remaining issues at our
WebEx call today.
I will be waiting for the next revision of the draft to formally confirm that.
 
Adrian and all,
 
Regards,
Sasha  
  _____  

From: Kamran Raza (skraza) <[email-masked]>
Sent: Wednesday, August 6, 2014 8:56 PM
To: [email-masked]
Cc: [email-masked]; Sami Boutros (sboutros);
[email-masked]; Alexander Vainshtein;
[email-masked]
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt 
 
Hi Adrian,
 
We (authors) just had a webex call with Sasha to discuss/close on his comments [
which we had also discussed over the email starting May ].
We all are in agreement/sync on the points that were raised during this review .
Almost all, if not all,  of the points/comments will be addressed by
clarifying the  scope of the extension in a new "Applicability" section with
risk and recommendations highlighted.

We thank you Sasha for his detailed review and useful comments and thank you for
your patience.
-
Kamran and Sami
 
From: Adrian Farrel <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, July 30, 2014 at 6:16 PM
To: Syed Kamran Raza <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Sami Boutros (sboutros)"
<[email-masked]>, "[email-masked]"
<[email-masked]>, 'Alexander
Vainshtein' <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

A
 
From: Kamran Raza (skraza) [mailto:[email-masked]] 
Sent: 30 July 2014 19:00
To: [email-masked]
Cc: [email-masked]; Sami Boutros (sboutros);
[email-masked]; 'Alexander Vainshtein';
[email-masked]
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt
 
Hi Adrian,
 
Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to
schedule the meeting post IETF as Sasha did not attend.
We are meeting tomorrow with Sasha to clarify/converge.
 
Thanks.

Kamran Raza
TECHNICAL LEADER.ENGINEERING
Product Development
 <mailto:[email-masked]> [email-masked]
Phone: +1 613 254 4520

 <http://www.cisco.com/> Cisco.com

Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3.
Phone: 416-306-7000; Fax: 416-306-7099.
 <http://www.cisco.com/offer/subscribe/?sid=000478326> Preferences -
<http://www.cisco.com/offer/unsubscribe/?sid=000478327> Unsubscribe -
<http://www.cisco.com/web/siteassets/legal/privacy.html> Privacy

Image removed by sender. Think before you print.

This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others is
strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
Please  <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>
click here for Company Registration Information.

From: Adrian Farrel <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran Raza <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Sami Boutros (sboutros)"
<[email-masked]>, "[email-masked]"
<[email-masked]>, 'Alexander
Vainshtein' <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt
 
Kamran,

 
cheers,
Adrian
 
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 11 May 2014 15:09
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Sami Boutros ([email-masked])
Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt
 
Hello,
 
I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. The purpose of the review is
to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html
 
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft. 
 
Document: draft-ietf-mpls-ldp-ip-pw-capability-07.txt
Reviewer: Alexander ("Sasha") Vainshtein    
Review date: 11-May-14
IETF LC End Date: 12-May-14
Intended status: Standards Track 
 
Summary:
 
I have significant concerns about this document and recommend that the Routing
ADs discuss these issues further with the authors.
These concerns mainly deal with potential negative impact of the mechanisms
(introduced in the draft) for disabling "non-negotiable" capabilities of LDP
sessions  with the techniques that could dynamically change the state of
"interest" in these capabilities for a given LDP session.  
Some of these mechanisms are already standardized by the IETF, e.g.,   L2VPN
auto-discovery (RFC 6074 <http://tools.ietf.org/html/rfc6074> ) and  dynamic
placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw
<http://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw/?include_text=1>
) while others -  LDP FRR using remote loop-free adjacencies
(draft-ietf-rtgwg-remote-lfa
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/?include_text=1>
)- are in advanced stages of the IETF process.   

I must admit that I did not follow closely the discussion of  the draft in
question in the MPLS WG; so it may well be that some of my concerns have been
already raised, considered and found not relevant.
I also do not know if the draft has ever been discussed in the PWE3, L2VPN and
RTG WGs.
 
One possible way to address these concerns would be by adding an Applicability
Statement section to the draft and discussing potentially problematic
combinations of mechanisms there.
I have discussed this option with the authors and, to the best of my
understanding, they have in general agreed to add such a section to the next
revision of the draft. 
 
General comments:
To the best of my understanding the sole purpose of the draft is  prevention of
" wasteful" distribution of state dealing with two non-negotiable classes of
FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC
5036 <http://tools.ietf.org/html/rfc5036> ) and PW FECs (i.e. PW Id FEC and
Generalized PW Id FEC defined in RFC 4447 <http://tools.ietf.org/html/rfc4447> )
to LDP peers that are "not interested' in this state. Such unnecessary
distribution would result in unnecessary waste of resources (memory and/or CPU
cycles) and hence should be avoided.  
 
The draft mentions that:
<quote>
 
The draft, however, does not mention that filtering policies provide much finer
granularity of control over distribution of labels than that supported by the
mechanism introduced in the draft. 
E.g., in a scenario when LDP is supposed to set up only "tunnel LSPs" between
PEs for L2 and L3 VPN applications, an appropriate policy allow distribution of
the just the FECs associated with Router IDs of the PEs but not, say FECs
associated with the subnets of their core-facing interfaces. IMHO and FWIW this
means that support of the mechanism defined in the draft would not eliminate the
need for the filtering policies.
 
I have discussed this point with the authors and they have agreed to add some
clarifying text.
 
I have also failed to understand how distribution of PW FECs could be wasteful.
Section 5.3.3  "Signaling Procedures" of RFC 4447
<http://tools.ietf.org/html/rfc4447>  explicitly states that:
<quote>
   In order for PE1 to begin signaling PE2, PE1 must know the address of
   the remote PE2, and a TAI.  This information may have been configured
   at PE1, or it may have been learned dynamically via some
   autodiscovery procedure.

My reading of the quoted text is that PW FECs are only distributed across
targeted LDP sessions with the known Remote PEs for specific PWs.
AFAIK, this is what actually happens in most existing implementations of PW
signaling with RFC 4447. 
What's more, many implementations, when required to set up a PW with a specific
remote PE, check for existence of a targeted LDP session with this PE, and set
it up implicitly if it does not exist; then they distribute PW FEC-to-label
binding via this session only. Implicit targeted LDP sessions are also
implicitly torn down when the last PW between  the given pair of PEs is torn
down.
I have discussed this point with the authors, but, as of the moment of writing
this review,  we did not yet reach full agreement on it.  

Initially I have failed to understand the following text fragment in the draft
(the problematic statements are marked with italics):
<quote>
   For Prefix-LSPs application type, the non-interesting state refers 
   to any state related to IP Prefix FEC (such as FEC label bindings, 
   LDP Status). This document, however, does not classify IP address 
   bindings as a non-interesting state and allows the advertisement of 
   IP Address bindings to facilitate other LDP applications (such as 
   mLDP) that depend on learning of peer addresses over an LDP session 
   for their correct operation.
<end quote>
After discussing this point with the authors I've understood that they refer to
exchange of the LSR addresses in the Address and Address Withdraw messages that
is required for mapping Next Hop IP addresses computed by the IGP to Next Hop
LSR. While initial misunderstanding may be specific to me,  I have suggested to
the authors to clarify this point with explicit references to specific LDP
messages and sections of RFC 5036 <http://tools.ietf.org/html/rfc5036> .
 
Major Issue:
 
The draft, which builds on the mechanisms defined in RFC 5561
<https://datatracker.ietf.org/doc/rfc5561/?include_text=1> ,  defines two ways
to manipulate distribution of "non-interesting state", since by default it would
be enabled
.         In the Initialization message. I assume that in this case the only
valid use case would be disabling distribution of non-interesting state
.         In the Capability message. This method could be both to disable and
re-enable distribution of state, but it could only be used if the peer supports
"Dynamic Announcement Capability".
 
My concern stems from the fact that the draft deals with "old" LDP applications,
so that the possibility that distribution of FEC-to-Label bindings can be
unilaterally disabled for PW- and Prefix-FECs is not taken into account in the
existing deployments and mechanisms.

Consider the case when a targeted LDP session between PE1 and PE2 has been set
just for the purpose of running ICCP between these devices (i.e., in the terms
of the ICCP draft they belong to the same RG). According to the example in
Section 5.1 of the draft, the PEs could then disable distribution of both PW
FECs and Prefix-FECs across such a session in their appropriate Initialization
messages.
 
The following (valid from my point of view) scenarios would make such a setting
highly problematic:
1.       The operator that manages both PE1 and PE2:
a.       Maintains some  VPLS instances in its network
b.      Initially maintains VPLS instances in both E1 and PE2, but without
overlap between the sets of these instances (so that there is no need to setup
PWs between PE1 and PE2)
c.       Uses BGP-based autodiscovery mechanisms for VPLS in its network as
described in RFC 6074
d.      Is required to extend one of the VPLS instances it maintains and that
already has presence in PE1 to have presence also in PE2:
                                                                i.      With
BGP-based autodiscovery, explicit configuration of just PE2 should suffice, the
person (or management application) that extends this instance does not have to
know about the rest of the locations where this VPLS instance is present
                                                               ii.      The
autodiscovery process (which does not depend on LDP) identifies PE1 as a peer
for the VPLS instance being defined in PE2, so that a PW between PE1 and PE2 is
now required 
                                                             iii.      The PW
setup process finds a targeted LDP session between PE1 and PE2 and tries to use
it for setting up the required PW
                                                             iv.      However,
PW setup would fails because distribution of PW FECs across the already existing
targeted LDP session between PE1 and PE2 has been disabled.
e.      If PE1 and PE2 support "Dynamic Capability Announcement", this could be
amended by enabling distribution of PW FECs prior to setting the required PW.
However, this would require substantial changes in the existing PW setup
procedures
f.        If even one of the PEs does not support "Dynamic Capability
Announcement", the existing targeted LDP session would have to be torn down and
re-established again. This would probably have serious implications for the
ICCP-based redundancy mechanism.
2.       A similar scenario could be encountered if the operator employs dynamic
setup of multi-segment PWs, and the PW routing mechanism decides that one of the
segments of a new MS-PW to be set up should run between PE1 and PE2.   Such a
situation could be probably prevented if the PW routing mechanism could learn
that PE1 and PE2 cannot be "directly connected", but, to the best of my
understanding, it would require changes in the already standardized MS-PW
routing mechanism.
 
I have discussed these cases with the authors, but we have not reached an
agreement on them yet. From my point of view, the Applicability Statement
section should address these concerns.
 
Consider now the case described in Section 5.2 of the draft, when a targeted LDP
session between PE1 and PE2 is initially used just for distribution of setup of
PWs, so that distribution of Prefix-FECs is disabled.
 
The following (valid from my point of view) scenario would make such a setting
highly problematic:
1.       The operator uses LDP for setting "Tunnel LSPs" in its network
2.       LFA-based LDP FRR (as per RFC 5286
<https://datatracker.ietf.org/doc/rfc5286/?include_text=1>  and Remote LFA draft
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/?include_text=1> )
is used as the mechanism for fast protection in the operator's network.
3.       Initially PE1 can protect all the LSPs passing through it using just
local LFA.
4.       The network topology changes (e.g., because new LSRs are added to it),
and in order to provide the required coverage, PE1 has to use PE2 as its "remote
LFA" for some destinations. 
a.       This would require distribution of Prefix-FECs across the targeted LDP
session between PE1 and PE2 - but it has been disabled
b.      If PE2 does not support "Dynamic Announcement Capability", then the only
way to amend the situation would be to tear down the targeted LDP session
between PE1 and PE2 and to set it up again - but this would negatively affect PW
traffic between PE1 and PE2.
 
I have discussed this case with the authors. To the best of my understanding,
they have agreed that combining LDP FRR based on Remote LFAs with the mechanisms
defined in the draft would be highly problematic, and will add some suitable
text to the Applicability Statement section in the next revision of the draft.

Minor Issues:
 
1.       The draft states (in section 4.2) that desire of a given LSR  of
reception of unnecessary state from the peer is "unilateral and unidirectional
by nature". 
a.       IMO this makes perfect sense for Prefix-FECs. 
b.      However, PW FECs must always be exchange in both directions of  a
targeted LDP session, so that disabling their distribution in just one direction
would effectively prevent setup of PWs between the given pair of PEs
2.       I concur with Adrian's comment in his AD review of the draft about
proposed encoding of states of non-interest.
3.        I also wonder whence the need for 16 potential states of non-interest
in the draft that, to the best of my understanding, deals with exactly 4 "old"
LDP applications. I hope that this does not imply possibility of developing new
"old-style' LDP applications in future (or discovering some forgotten old
ones?).
 
I have not yet discussed these issues with the authors (as we concentrated on
the major ones).
 
Nits:

Spelling and Grammar:

Regards,
       Sasha 
Email: [email-masked]
Mobile: +972-54-9266302