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

From: Kireeti Kompella <[email-masked]>
Date: Wed, 16 Sep 2020 07:40:06 -0700

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 <
[email-masked]> 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

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 28 Sep 2020 21:32:29 +0000

Hi Kireeti,

Thank you for addressing the comments. It looks good to me.

Thanks,
Nagendra

From: Kireeti Kompella <[email-masked]>
Date: Wednesday, September 16, 2020 at 10:40 AM
To: Nagendra Kumar <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Opsdir last call review of draft-ietf-mpls-rmr-12

Hi Nagendra,

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.

Thanks again,
Kireeti.

On Tue, Nov 5, 2019 at 7:49 PM Nagendra Kumar via Datatracker <[email-masked]<mailto:[email-masked]>> 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:

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

--> Same as above.

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

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

It further says:

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

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

Few nits:

Thanks,
Nagendra

--
Kireeti