Hi Kireeti,
Thank you for addressing the comments. It looks good to me.
Thanks,
Nagendra
From: Kireeti Kompella <kireeti.kompella@xxxxxxxxx>
Date: Wednesday, September 16, 2020 at 10:40 AM
To: Nagendra Kumar <naikumar@xxxxxxxxx>
Cc: "ops-dir@xxxxxxxx" <ops-dir@xxxxxxxx>, "draft-ietf-mpls-rmr.all@xxxxxxxx" <draft-ietf-mpls-rmr.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "mpls@xxxxxxxx" <mpls@xxxxxxxx>
Subject: Re: Opsdir last call review of draft-ietf-mpls-rmr-12
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.
On Tue, Nov 5, 2019 at 7:49 PM Nagendra Kumar via Datatracker <noreply@xxxxxxxx> 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
--
|
