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

[Kireeti Kompella <[e-mail]>]

Hi Nagendra,

This has been a while -- apologies!

Thank you for your review and detailed reading -- some nice catches.

The -13 update addresses all your concerns, I believe.  Section 1.2
captures the changes; those specific to this review are marked with [OPS].

In particular, Section 3.6 was rephrased to address your first set of
comments; sections 4.3 and 4.4 the next set of comments regarding
mastership election and ring identification; section 4.1 was updated to
change Ring Neighbor TLV to Ring Link TLV.  Finally, SPRING was changed to
IGP in list of signaling protocols, and the reference to the draft was
updated to RFC 8029.

I think that covers all your comments.

Thanks again,
Kireeti.

On Tue, Nov 5, 2019 at 7:49 PM Nagendra Kumar via Datatracker <
[e-mail]> wrote:

> 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
>
>

-- 
Kireeti