Re: [mpls] [Reminder] RE: Routing directorate review of draft-ietf-mpls-ldp-mrt

[Chris Bowers <[e-mail]>]

I apologize for the long delay.

Thanks for the RTGDIR review.
The responses and/or textual changes in response to that review are shown below with [CB].

I also addressed the request in Loa’s Shepherd write-up to move RFC2119 to normative references and to adjust the RFC2119 boilerplate.
https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/347aa102a20ef70b8ae70e8e4f83f990265b6c79

I went ahead and published an update on the IETF website.

https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/

Thanks,
Chris


From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
Sent: Thursday, April 20, 2017 12:49 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: FW: [Reminder] RE: Routing directorate review of draft-ietf-mpls-ldp-mrt

Authors,

Here’s our Routing Directorate reviewer’s comments. Please address the comments by responding to Tony and the list.

Thanks,
Deborah


From: Tony Przygienda [mailto:[e-mail]]
Sent: Thursday, April 20, 2017 1:28 PM
To: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>
Cc: Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Reminder] RE: Routing directorate review of draft-ietf-mpls-ldp-mrt

Here's the review (sorry for delay, lots of material). Pls fwd to according mailing lists

----


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, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=2alVGKgP_GREqRqvbnBZVqcgclwC7efVibS2GkUmJjc&s=JOA5mn5ikG_Osb6EtJOk-J0q5a9a__O55zqUSzk_Ck8&e=>

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-mrt
Reviewer: Tony Przygienda
Review Date: 4/20/17
Intended Status: Standards Track

Summary:

I have several major comments that either indicate technical inconsistencies in the MRT-FRR document set (7811/7812/igp/ldp drafts) or suggest additions to improve readability of those documents and prevent wrong assumptions on the reader's side.


Major Comments:


·         A small section outlining the requirements of “domain-alignment” in MRT could be helpful, i.e. what are the assumptions as to congruency of LDP/IGP areas/MRT islands and features supported in each. A picture of where the proxy nodes fit in, where the rainbow labels are used, a GADAG root would improve readability. MRT has good amount of moving parts that relate in non-obvious ways. This comment is geared probably more toward RFC7812 than this document.



========================

[CB]  The question of the congruency of LDP and IGP domains is addressed in the section added below “Interaction of MRT-related LDP advertisements with the MRT topology and computations.”



https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/4ad4bc50a35f24be6b24365287a148bc7cbdcdf9





That seems appropriate for this doc since it involves the LDP domain.  Are you OK with this section to cover this comment as a whole?

I am reluctant to put more material in this document if that should really be in RFC7812, since it might end up creating more confusion about normative things in 7812 than it helps in clarify this doc.



========================

·         It seems that the implicit assumption that the IGP MRT support is congruent with the LDP MRT support, i.e. LDP MRT capability is advertised IIF if the node supports MRT in IGP on the link (and vice versa)? Otherwise section 5.2 is ambiguous as in “is LDP on anything that will be on red or blue assumed/a MUST” or “IGP shall not compute red/blue if LDP peer is not MT-MRT-capable, i.e. take the link out the MRT topology” ?  If such an assumption is made, spelling it out would improve readability of the document.

========================

[CB] I added the following section to clarify this.



https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/4ad4bc50a35f24be6b24365287a148bc7cbdcdf9


4.4.  Interaction of MRT-related LDP advertisements with the MRT
      topology and computations

   [RFC7811] and [RFC7812] describe how the MRT topology is created
   based on information in IGP advertisements.  The MRT topology and
   computations rely on on IGP advertisements.  The presence or absence
   of MRT-related LDP advertisements does not affect the MRT topology or
   the MRT-Red and MRT-Blue next-hops computed for that topology.

   As an example, consider a network where all nodes are running MRT IGP
   extensions to determine the MRT-topology, which is then used to
   compute MRT-Red and MRT-Blue next-hops.  The network operator also
   configures the nodes in this network to exchange MRT-related LDP
   advertisements in order to distribute MPLS labels corresponding to
   those MRT next-hops.  Suppose that, due to a misconfiguration on one
   particular link, the MRT-related LDP advertisements are not being
   properly exchanged for that link.  Since the MRT-related IGP
   advertisements for the link are still being distributed, the link is
   still included in the MRT topology and computations, In this
   scenario, there will be missing MPLS forwarding entries corresponding
   to paths that use the misconfigured link.

   Note that the situation is analogous to the interaction of normal LDP
   advertisements and IGP advertisements for shortest path forwarding.
   Deactivating the distribution of labels for normal shortest path FECs
   on a link does not change the topology on which the SPF algorithm is
   run by the IGP.



========================

·         Proxy node attachment router in section in 5.1.2 is loosely introduced and would benefit from reference to Section 11.2 in 7812. A clear definition with distinction between the “proxy node” and “proxy node attachment" in the glossary (of RFC7812?) would help the reader of the document set.



=================

[CB]  I added a reference to section 5.9 of RFC 7811.  The current text now reads.



   Section 11.2 of [RFC7812] describes how MRT provides FRR protection

   for multi-homed prefixes using calculations involving a named proxy-

   node.  This covers the scenario where a prefix is originated by a

   router in the same area as the MRT Island, but outside of the MRT

   Island.  It also covers the scenario of a prefix being advertised by

   a multiple routers in the MRT Island.



   In the named proxy-node calculation, each multi-homed prefix is

   represented by a conceptual proxy-node which is attached to two real

   proxy-node attachment routers.  (A single proxy-node attachment

   router is allowed in the case of a prefix advertised by a same area

   router outside of the MRT Island which is singly connected to the MRT

   Island.)  All routers in the MRT Island perform the same calculations

   to determine the same two proxy-node attachment routers for each

   multi-homed prefix.  [RFC7811] describes the procedure for

   identifying one proxy-node attachment router as "red" and one as

   "blue" with respect to the multi-homed prefix, and computing the MRT

   red and blue next-hops to reach those red and blue proxy-node

   attachment routers.





=================

·         I don’t see a specification how non-default profiles would be supported in the future in this document. It seems implied that negotiating certain MT-IDs in LDP will imply certain profile values in the future but the document would gain readability if that is spelled out (I think RFC7812 does indicate that in 8.1 already so reference maybe enough). However when reading 5.1 of draft-ietf-isis-mrt-02 I see  that the profile ID is explicity given with the topology ID which seem contradictory if topology IDs imply the profile used.

=================

[CB] I added a reference to section 8.1 of RFC7812 and repeated the text from there for clarity.



Section 4.3 of this draft now reads.



4.3.  MRT-Blue and MRT-Red FECs



   To provide MRT support in LDP, the MT Prefix FEC is used.  [RFC7812]

   defines the Default MRT Profile.  Section 8 of the current document

   specifies the values in the MPLS Multi-Topology Identifiers Registry

   for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default

   MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).



   As described in Section 8.1 of [RFC7812], when a new MRT Profile is

   defined, new and unique values should be allocated from the "MPLS

   Multi-Topology Identifiers Registry", corresponding to the MRT-Red

   and MRT-Blue MT-ID values for the new MRT Profile.



   The MT Prefix FEC encoding is defined in [RFC7307] and is used

   without alteration for advertising label mappings for MRT-Blue, MRT-

   Red and Rainbow MRT FECs.



The text in draft-ietf-isis-mrt-02 needs to be clarified on this point, but it is not a normative reference for

draft-ietf-mpls-ldp-mrt.



=================



·         I find it surprising that the document does not describe in section 5 the interaction of different LDP modes and the MRT computations. Do we do unsolicited  liberal, retain when MRT computed the next-hops and so on?  Maybe one sentence along the lines of “LDP mode must be the same as unicast IGP forwarding mode” would help clarify or the specific necessary modes listed.


=================
[CB]I added the following text.
https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/aed586041110cc64f3ac76376e8885ea5450d47e


   [RFC5036] specifies two different Label Distribution Control Modes

   (Independent and Ordered), two different Label Retention Modes

   (Conservative and Liberal), and two different Label Advertisement

   Modes (Downstream Unsolicited and Downstream on Demand).  The current

   specification for LDP MRT requires that the same Label Distribution

   Control, Label Retention, and Label Advertisement modes be used for

   the shortest path FECs and the MRT FECs.



=================

Minor comments:


·         For easy reference suggest to add “two-connected graph” to the glossary since it’s not a common term. Or refer to  RFC7812



·         Maybe same for “cut-vertex” or refer to 7812

=================
[CB]I added the second sentence in the following text.



   For ease of reading, some of the terminology defined in [RFC7812] is

   repeated here.  Please refer to the Section 3 of [RFC7812] for a more

   complete list.



================





·         Maybe same for “topological ordering”. Reference to 7811 would be helpful for readability



=================

[CB] I shortened the definition of MRT-Red and MRT-Blue to not refer to topological order.  I think this is a good solution

because it is a distraction in this draft that focused on LDP aspects.



https://github.com/cbowers/draft-ietf-mpls-ldp-mrt/commit/a9407974c5873e3850c050549a2506a66714e626




      <t hangText="MRT-Red: ">  MRT-Red is used to describe one of the two MRTs; it is
       used to describe the associated forwarding topology and MPLS
-      Multi-Topology IDentifier (MT-ID).  Specifically, MRT-Red is the
-      decreasing MRT where links in the GADAG are taken in the direction
-      from a higher topologically ordered node to a lower one.</t>
+      Multi-Topology IDentifier (MT-ID).</t>

      <t hangText="MRT-Blue: "> MRT-Blue is used to describe one of the two MRTs; it is
       used to described the associated forwarding topology and MPLS
-      MT-ID.  Specifically, MRT-Blue is the increasing MRT where links
-      in the GADAG are taken in the direction from a lower topologically
-      ordered node to a higher one.</t>
+      MT-ID. </t>





=================



thanks



--- tony