Re: [mpls] MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr

Rakesh Gandhi <rgandhi.ietf@gmail.com> Thu, 18 June 2020 12:48 UTC

Return-Path: <rgandhi.ietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2333A0D21; Thu, 18 Jun 2020 05:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKbaVRddq5HM; Thu, 18 Jun 2020 05:48:18 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA343A0D1D; Thu, 18 Jun 2020 05:48:17 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id i3so7079771ljg.3; Thu, 18 Jun 2020 05:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mh4AULnUIVXDfMixJjnReMqUqDnrzj4hVsTBydqPUa0=; b=JfroCDAH0mwHCkxbmlpYRw1gWkt1pxJRzWyAmdbZKOoimm3MrNhv98KVTgxqEls+28 +UDetiaSwgLNOpxJ88+8UyvSgP8sP8H6LMmFXbg13B9vR7NG04lKck/VzjK/vxU2x6HL Tr3A53Uq74AtXL+a9SOCSvmh4AEQ0ZMxwaWCFN4d6YP12AjfExraEy3vG+5uLouaegfC KH7xexVWMG0lkjcmjLWhwTwohJjQNrUpYNBdf3tNgBtbrKkYWBYxcuw7U8cOAhbD86bv vIyHNu0pcm/XCPO2DzIqjJy72S8XpkQlz74qcfu+ikBO/aRWCkThCwwXj/h8+UTMXIN0 ZQ2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mh4AULnUIVXDfMixJjnReMqUqDnrzj4hVsTBydqPUa0=; b=I1VEhbwW8L2Wo6+qEbKhWqus8auWa+hpyi+kb7Ufh/06R+kYt56Sy7H7p0G3OOIFPT 7+5KSOZNvZlCKu8ADcjouECi7xeoic6RLZBrzay1nSahh2K51SqC8zzg+aPTJ9jCa+bk XExc7DQBEEPzFMITdS+avntkKBr9fT4U+KAzBnrLo3xNCSJZfYWF9YXnsZsZYnmF4ty0 XJAaMX2iKLuoUkUc3Qzes9WUCQYYPPSdvIp3ZZaRfZAH5WLf0pSQDp+awA98QsOyUCLT M6S8/3Q3URA7wpH2hVLPNxgZYs+TWEaNyvc9gpQU+BrINaeBjpPgTrG/a5/vI416EfNn mM3g==
X-Gm-Message-State: AOAM5321Mt87JqhH/jFabeaU/jGDUMJ/nc7Se3hnzER9EpwNcKQQ6IQ/ CRkmQvHDzkRpoOUC0zBuvqAnKOU/xO9t9wFPWg==
X-Google-Smtp-Source: ABdhPJx34varZAzd36yA2oVvidWESRgkKNZoMJH1jDFoplGeBir/Ev9Q06+kCo4yFmnIK/JMQWLoOj451IQWNKuucZM=
X-Received: by 2002:a2e:a54f:: with SMTP id e15mr2457757ljn.263.1592484495498; Thu, 18 Jun 2020 05:48:15 -0700 (PDT)
MIME-Version: 1.0
References: <CH2PR19MB40241A395AAD7976CD74FE11FCA40@CH2PR19MB4024.namprd19.prod.outlook.com> <CH2PR19MB4024716E9AC140055BE4DBB9FC880@CH2PR19MB4024.namprd19.prod.outlook.com> <CAEz6PPS834DE01HX3h-3sL_Ew6J+dP89XSyjC-19cVQuiVbv_Q@mail.gmail.com>
In-Reply-To: <CAEz6PPS834DE01HX3h-3sL_Ew6J+dP89XSyjC-19cVQuiVbv_Q@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Thu, 18 Jun 2020 08:48:04 -0400
Message-ID: <CAMZsk6cKDUpYXsJG9VYPG+ADd3bWaxS9OX7QG_9ttTgaVTOQbg@mail.gmail.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: Tarek Saad <tsaad.net@gmail.com>, mpls@ietf.org, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa227b05a85b304e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/NJyK3MSQvWBZSYDXvG_XXFbIoLU>
Subject: Re: [mpls] MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 18 Jun 2020 12:48:19 -0000

Thank you Xufeng for the review.
Please see replies inline with <RG>...

On Wed, Jun 17, 2020 at 1:12 PM Xufeng Liu <xufeng.liu.ietf@gmail.com>
wrote:

> Hi Authors and WG,
>
>
> I have reviewed the document draft-gandhi-mpls-rfc6374-sr and have the
> following comments.
>
>
> 1. Using the existing mechanism defined by RFC 6374 for SR PM is natural,
> logical, and worth proceeding.
>

<RG> Many thanks.

>
> 2. The 2nd paragraph in Sec 2.3 describes the case P2MP, but the context
> is the reference topology depicted as Figure 2, which does not clearly
> cover the P2MP case. Some additional clarification or a different topology
> may illustrate better.
>

<RG> Moved the text to the relevant section 7 along with other P2MP texts
to avoid confusion.

>
> 3. In the last paragraph in Sec 4.2 describes the use of Destination
> Address TLV. Does the statement “can be sent in the probe query message”
> mean that this is optional? (Is this MAY or MUST?) An implementer would
> like to know the clear requirement.
>

<RG> Added  "MAY".

>
> 4.. Sec 4.3.3. describes the loopback measure mode, which requires the
> responder to collect timestamps t1 and t4. Such a behavior does not seem to
> follow RFC 6374. Based on Sec 3.5.3. of RFC 6374, “no support for delay
> measurement is required at the responder at all, other than the ability to
> recognize a DM query that includes this object and return it unmodified.”
>

<RG> The responder does not add t1 and t4 (as per Reference Topology). The
responder simply forwards the probe packet.

>
> 5.. The last sentence of Sec 4.3.3. excludes the loopback mode for
> SR-MPLS Links. Is there any reason for the exclusion?
>
>
>
<RG> Removed.

6. Most of the document describes the procedures to use RFC 6374. The only
> additions to RFC 6374 are Sec. 4.4. and Sec. 6.2., but these two sections
> are embedded in the other sections on procedures and use cases. For an
> implementer, I’d hope to see these two sections separated from others so
> that it would be clear what are needed to implement on top of the protocol
> defined in RFC 6374.
>

<RG> Keeping them at the current place provides context and continuity for
reading. It is highlighted in Abstract and Introduction that these two TLVs
are new.
I am afraid, moving them elsewhere may lose the context. Please advise if
you have a preference.

Thanks,
Rakesh


> Thanks,
>
> - Xufeng
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>