[mpls] Opsdir last call review of draft-ietf-mpls-rmr-12

Nagendra Kumar via Datatracker <noreply@ietf.org> Wed, 06 November 2019 03:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EE12006F; Tue, 5 Nov 2019 19:49:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Nagendra Kumar via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-mpls-rmr.all@ietf.org, last-call@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Nagendra Kumar <naikumar@cisco.com>
Message-ID: <157301215312.30434.523306736500548236@ietfa.amsl.com>
Date: Tue, 05 Nov 2019 19:49:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/k5I6K13VnS-qaTiOkPYbCJmVWsQ>
Subject: [mpls] Opsdir last call review of draft-ietf-mpls-rmr-12
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 03:49:13 -0000

Reviewer: Nagendra Kumar
Review result: Has Issues

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