Last Call Review of draft-ietf-mpls-rmr-12
review-ietf-mpls-rmr-12-opsdir-lc-kumar-2019-11-05-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-mpls-rmr-12-opsdir-lc-kumar-2019-11-05

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing resiliency solution for RING topology.Overall this is a well written document. Some ambiguities that need attention are listed below. 

More details below:

Section 3.6 proposes the below:

There are three proposals to avoid this:

   1.  Each ring node acting as ingress sends traffic with a TTL of at
       most 2*n, where n is the number of nodes in the ring.

--> I think the ring in most of the case will be transit where the LSP may extend beyond the ring.  I think, setting the TTL to 2*n may affect the regular traffic. For example if the ring is of size 3 connecting other ring nodes to AGG/Core. When it receives a labeled packet with TTL of 250 and if it pushes RING label with a TTL of 6, it will end up rewriting the inner TTL to a much lesser value. Am I missing something?.

   2.  A ring node sends protected traffic (i.e., traffic switched from
       CW to AC or vice versa) with TTL just large enough to reach the
       egress.

--> Same as above. 

   3.  A ring node sends protected traffic with a special purpose label
       below the ring LSP label.  A protecting node first checks for the
       presence of this label; if present, it means that the traffic is
       looping and MUST be dropped.

--> To me, this looks like a better option comparing to the above 2.

If it is the node with the lowest loopback address of all nodes with
   the highest mastership values, N declares itself master by
   readvertising its ring node TLV with the M bit set.

--> When the loopback address of Node N1 is lowest but the MV is not the highest, what will be the behavior?. Since loopback address is unique, I think N1 can still declare itself as the master. But I am trying to understand the need for MV. 

When there is exactly one ring master M (here, R2), M enters the Ring
   Identification Phase.  M indicates that it has successfully completed
   this phase by advertising ring link TLVs. 

--> Section 4.1 defines Ring Node TLV and Ring Neighbor TLV. The above section talks about Ring Link TLV. But I couldn't find any reference or details about this TLV in the draft.

Section 4.4 says,

"M indicates that it has successfully completed
   this phase by advertising ring link TLVs.  This is the trigger for
   M's CW neighbor to enter the Ring Identification Phase.  "

It further says:

"If not, X computes a ring that includes all nodes that have
   completed the Ring Identification Phase (as seen by their ring link
   TLVs) and further contains the maximal number of nodes that belong to
   the ring. "

--> From the first statement, I am assuming that node M will advertise Ring Link TLV after it selects CW and AC neighbors. so that the CW neighbor can enter the Ring Identification phase. But the identification phase on M appears to rely on neighbors that have completed Ring Identification phase. Wont M end up waiting for Rink Link TLV from neighbors to start the election while the neighbors are waiting for Ring Link TLV to enter Ring Identification phase?. Did I misunderstood the election process?. 


SS: Supported Signaling Protocols
        (100 = RSVP-TE; 010 = LDP; 001 = SPRING)

--> I think technically SPRING is not a label signaling protocol. Instead, it should be IGP.

Few nits:

s/I-D.ietf-mpls-rfc4379bis/RFC8029

Thanks,
Nagendra