LDP Extensions to Support Maximally Redundant Trees
RFC 8320

Note: This ballot was opened for revision 06 and is now closed.

(Deborah Brungard) Yes

(Ben Campbell) No Objection

Comment (2017-09-13 for -06)
No email
send info
-3: The definition of "Island Neighbor" appears to be a copy of the definition of "Island Border Router". Is that intentional?

(Benoît Claise) No Objection

Comment (2017-09-13 for -06)
No email
send info
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.

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2017-09-11 for -06)
No email
send info
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!

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2017-09-09 for -06)
No email
send info
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.

Alvaro Retana No Objection

Comment (2017-09-13 for -06)
No email
send info
(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?

(Adam Roach) No Objection

Comment (2017-09-13 for -06)
No email
send info
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.

(Alia Atlas) Recuse

Comment (2017-09-12 for -06)
No email
send info
I did notice a couple minor nits:

1) draft-ietf-mpls-mldp-node-protection is now RFC 7715.

2) In Terminology: "Island Border Router (IBR): A router that is not in the MRT Island
      but is adjacent to an IBR and in the same area/level as the IBR."
  This is the definition for an Island Neighbor. 
 The correct definition from
RFC 7812 is: " Island Border Router (IBR): A router in the MRT Island that is
      connected to a router not in the MRT Island, both of which are in
      a common area or level."