LDP Extension for Inter-Area Label Switched Paths (LSPs)
draft-ietf-mpls-ldp-interarea-04

[Ballot comment]
Although the document does not include a dedicated Operational and Manageability considerations section valuable information about configurability and deployment is described in sections 5 and 7. This is fine but one piece of information would be worth adding. The first paragraph in section 5 says:

  This document defines a new label mapping procedure for [LDP]. It is
  applicable to IPv4 and IPv6 prefix FEC elements (addresses families 1
  and 2 as per [ASSIGNED_AF]). It MUST be possible to activate /
  deactivate this procedure by configuration and it SHOULD be
  deactivated by default. It MAY be possible to activate it on a per
  prefix basis.

This alludes to the need to add new management objects to the MPLS MIB modules, including a way to activaye/deactivate the label mapping procedure per prefix and a DEFAULT value for this object. I suggest that appropriate wording about future work on this respect is added to Section 5.

[Ballot discuss]
This is a discuss-discuss:

The document doesn't specify any mechanism for discovering whether a
particular router implements the original RFC 5036 behavior or the new
behavior. I'm assuming the deployment plan is something like "(1)
update all routers; (2) when you think you're done, stop
redistributing the specific LER addresses; (3) find out what broke".
Is this a realistic deployment plan? (It might be -- this is not
really my area of expertise)

[Ballot comment]
Section 3.5.7.1, paragraph 0:
>    However, [LDP] requires that the IP address of the FEC Element should
>    *exactly* match an entry in the IP RIB: according to [LDP] section
>    3.5.7.1 (Label Mapping Messages Procedures) "An LSR receiving a Label
>    Mapping message from a downstream LSR for a Prefix SHOULD NOT use the
>    label for forwarding unless its routing table contains an entry that
>    exactly matches the FEC Element.".

  Inaccuracy: The quoted RFC says "SHOULD NOT", the first sentence of
  this paragraph claims that as a requirement, which it isn't in the
  RFC2119 sense - it's a recommendation.


Section 3.5.7.1, paragraph 1:
>    Therefore, MPLS LSPs between LERs in different areas/levels are not
>    setup unless the specific (e.g. /32 for IPv4) loopback addresses of
>    all the LERs are redistributed across all areas.

  Nit: expand LER

[Ballot discuss]
Several points that I'll try to make as coherent as possible ...

- My biggest issue is that the draft doesn't solve the problem it set out to solve and has no scale benefits.  It addresses to some degree the control plane aspects - allowing the IGP to summarize.  But this is very small compared to updating the data plane. They get rid of the /32 IP routes in the data plane, but still require labels for all those routes.  All such labels may need to be updated on a re-convergence event.

- Next, the idea ties BGP NH tracking directly to LDP. The major con is that NHs are provided the IGP and NH tracking should not be completed via ordered LDP update/withdraw but, the IGP. The clear drawback is the change to BGP NH validation.

- In the end, the only reason  for deploying this draft would be  that you want each P  router to have an LSP for  each /32 PE router  address, so that  you can  take advantage  of LDP-based  FRR.  Since there is no such thing as LDP support for FRR, this seems a poor reason. 

DISCUSS DISCUSS
- There are multiple competing solutions in this space from a variety of authors. Pushing this one forward to PS with no known implementations (choice of the MPLS WG) and knowing that other more complete solutions are being proposed seems to give us a chance to pause to think through the entire solution space. I highly recommend we convene a discussion of MPLS saavy folks and work through the possible solutions that will have to be considered and see if we can reduce from the three known to "the chosen one." Unfort., I don't think it will be this one.

[Ballot discuss]
Several points that I'll try to make as coherent as possible ...

- My biggest issue is that the draft doesn't solve the problem it set out to solve and has no scale benefits.  It addresses to some degree the control plane aspects - allowing the IGP to summarize.  But this is very small compared to updating the data plane. They get rid of the /32 IP routes in the data plane, but still require labels for all those routes.  All such labels may need to be updated on a re-convergence event. After talking w/ the author (Bruno) he agrees that the draft has no scale benefits.

- Next, the idea ties BGP NH tracking directly to LDP. The major con is that NHs are provided the IGP and NH tracking should not be completed via ordered LDP update/withdraw but, the IGP. The clear drawback is the change to BGP NH validation.

- In the end, the only reason  for deploying this draft would be  that you want each P  router to have an LSP for  each /32 PE router  address, so that  you can  take advantage  of LDP-based  FRR.  Since there is no such thing as LDP-based FRR, this seems a poor reason. 

DISCUSS DISCUSS
- There are multiple competing solutions in this space from a variety of authors. Pushing this one forward to PS with no known implementations (choice of the MPLS WG) and knowing that other more complete solutions are being proposed seems to give us a chance to pause to think through the entire solution space. I highly recommend we convene a discussion of MPLS saavy folks and work through the possible solutions that will have to be considered and see if we can reduce from the three known to "the chosen one." Unfort., I don't think it will be this one.

LDP extension for Inter-Area LSP
(draft-ietf-mpls-ldp-interarea-03.txt )


Requested Publication Status: Proposed Standard

------------------------------------------------------------------------

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes.

Both mpls wg co-chairs reviewed this version of the ID. Based on the WG
comments, we believe the ID is ready for publication.

1.b) Has the document had adequate review from both key WG members
and key non-WG members?

Yes, the document has been through wg last call with good and constructive
comments, it has also been reviewed by subject-matter experts that are
WG members.

Do you have any concerns about the
depth or breadth of the reviews that have been performed?

No.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No, this is core mplstechnology and we have the expertise within the wg.



1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No. The internet-draft was produced by working group memebers with
expereince from LDP implentations and testing.


1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document represents the WG consensus as a whole: the WG as a whole
understands and agrees with it.



One comment we seen is that this is possibly not enough to solve the
interarea scalability problems with regards to the number of PE/LSPs,
however it is good step in the right direction.



1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No.

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

There are two ID nits issues per the automated ID nits check.

- the informatively referenced IDs has been publsihed as an RFC
- one IP prefix is wrongly repreented as 192.0.0/16 and should be changed
to 192.0/16


We suggest that both nits should be fixed from RFC-Ed notes

1.h) Is the document split into normative and informative references?

Yes.

Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

No; the reference cited above was an informative reference

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Please provide such a write-up. Recent examples can be found in
the "protocol action" announcements for approved documents.

--- Technical Summary

OSPF and IS-IS allow the partition of an autonomous system into areas
or levels to increase routing scalability within a routing domain.

However, LDP requires that the IP address of the FEC Element should
match an entry in the IP RIB exactly.

This makes it necessary to distribute /32's, (e.g. loopback addresses)
between areas in order to be abel to setup MPLS LSPs between LERs in
different areas (levels). All the specific addresses for all the LERs
has to be distributed across all areas.

This document extends the Label Mapping Procedure defined in LDP to
support the setup of contiguous inter-area LSPs while maintaining IP
prefix aggregation on the ABRs. This basically consists of allowing
for "Longest Match Based" Label Mapping.


--- Working Group Summary

The Working Group has consensus to publish this document as a
Proposed Standard.

--- Protocol Quality

The document has been reviewed by experts form the MPLS working
group as well as being lst called in the working group, the comments
received from the experts and the working has been addressed and
the document updated.

--- Implementations

We know about one implementations of the specification.