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: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>
Mobile: +972-54-9266302