LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-07

Section 4.1 defines some reserved bits in the new MRT capability TLV format. Typically, we specify that reserved bits are set to 0 on send and ignored on receive, to allow for future definition of a purpose for them.

(1) I think that Section 4.4. (Interaction of MRT-related LDP advertisements with the MRT topology and computations) would benefit from a reference to rfc5443 (LDP IGP Synchronization).

(2) From Section 5: "The associated LSPs must be created before a failure occurs..."  Should that be a Normative MUST?

-3: The definition of "Island Neighbor" appears to be a copy of the definition of "Island Border Router". Is that intentional?

Editorial feedback (Tim Chown's OPS DIR review): 

There are a number of typos in the document that I would expect the RFC Editor
to pick up, but it would be nice to correct these before pushing the document,
e.g., "Extension" singular on page 3, or "as foll If" on page 10.

Line 106
   familiar with the architecture in [RFC7812] to understand how and why
   the LDP extensions for behavior are needed.

It would actually be helpful to explain this here.


Line 430
   However, should this situation occur, the expected behavior of an LSR
   receiving these conflicting advertisements is defined as foll If an
   LSR receives a label mapping advertisement for a rainbow FEC from an

Nit: as follows.

1) I was just wondering if it was considered to just use one flag of the reserved field of the multi-topology extension in RFC7307 to advertise MRT support, given that MT must always advertised as well...?

2) Why would a node withdraw the MRT capability/ when would it send a MRT advertisement with S=0?

3) If you update the document, please also see the gen-art review: there are many small nits which will probably also be caught by the RFC editor but if you can fix them now, that's even better!