Re: [spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Tue, 26 January 2021 16:58 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA89A3A0AD6; Tue, 26 Jan 2021 08:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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, UNPARSEABLE_RELAY=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 kLgnu3L_SI_7; Tue, 26 Jan 2021 08:58:04 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 24BB83A0AF8; Tue, 26 Jan 2021 08:57:53 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id ox12so24009414ejb.2; Tue, 26 Jan 2021 08:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4ItmlBbosSb66r2CaFtn67zNmNdindWbm/hq+2KyJm8=; b=KjNpsjD4NNYkcV4EAP7eWfa4ASjOuLjmYpOL0THOGuuO8F1cGyxSW0KohtpT9uXNN5 mBr2SZubUpIm1pPI8EDR6dsV8qJfUMIWLQZoOrn5/jfn0p7LG38hY9L5z1oFgEofcF74 TgTroXjbXRgYHx0SUcV+x5a1ggH60W4e7SRzxnePdwIK5cHq3g6Q3OV/bsyISObcem/Z UB50Ctfs2b87t9RXuO5Mw2allGVP3F9AQXmkcFzRsI1tO59ZvHZ7agq+HPdKjK/pSJOj smo+gB8tOoZ6d+AlyytSyzI7SWJ0RPD6EErYVZwjWVqXWlaMLDCS6bYmt+oyvWYye5QG jg3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=4ItmlBbosSb66r2CaFtn67zNmNdindWbm/hq+2KyJm8=; b=O7IE9AdE/utQ6nS04IScZzSySL6rfgEtQBqJuorzl51sTfo6f68F/6hcD16ouok/8g ZeOY6PPBwyKnweibNvwoqfNZBpq0fAIR1r2lFmuCkojAFvJa8Cj184VNMpb2MgCdJaf+ 7sdJIjekbD3ZSUVzpFW6mrUIMAfVHrGSjsTaKO4ZBZGw1iPM7QwvKgCvicMCpYEiqH7O a/tczhFnqnLF3l9vuZsEMtkiYhr5049AN0EI9qA/zHVet+ytkNqCzFf4WuM9KeRT3NxA SSuaYRDBKyqNxauIP6p+odW6wBDcaffA1Udgg3TTJbff3k8tn4Wkddczqnc8zsUtA0Vf HTmQ==
X-Gm-Message-State: AOAM532hlr/U+DYwcpadcFewQVjjJe8o/bCPb1tOdrlbDh8Sbown10Zf m15kGpwTDxtvhVDLFZTCSJhHF0MpKL1dOUmJgCxbUnYPghk=
X-Google-Smtp-Source: ABdhPJxeyn1yyeTfh/YXnQlSbnyjwDeWAHcxgTDFT50UYjOqaUhY3SrfiZhiIu50jzjxFXX6VvlYDe+CRYbupQJ8Jco=
X-Received: by 2002:a17:906:6b02:: with SMTP id q2mr4206334ejr.122.1611680271739; Tue, 26 Jan 2021 08:57:51 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 26 Jan 2021 08:57:50 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <29454C46-79E4-4C1C-B6CC-86689AF50F39@futurewei.com>
References: <161115696601.10370.4919077195510776918@ietfa.amsl.com> <29454C46-79E4-4C1C-B6CC-86689AF50F39@futurewei.com>
MIME-Version: 1.0
Date: Tue, 26 Jan 2021 08:57:50 -0800
Message-ID: <CAMMESsyWORPesco=0KU_TOKjWNLkkiVgLcVvx-2BfA-5kE7QEQ@mail.gmail.com>
To: Yingzhen Qu <yingzhen.qu@futurewei.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-spring-sr-yang@ietf.org" <draft-ietf-spring-sr-yang@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016adc105b9d08ed5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/o-duzqYmhJQ-0D6Rv_LJR1Nxwdg>
Subject: Re: [spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 16:58:07 -0000

Hi!

The changes look good to me.

Thanks!

Alvaro.

On January 25, 2021 at 11:50:44 PM, Yingzhen Qu (yingzhen.qu@futurewei.com)
wrote:

Hi Alvaro,

Thank you for your thorough review and comments. We just published version
-30 to address IESG review comments. Please see detailed answers below
inline.

Please let us know if you have more comments.

Thanks,
Yingzhen

On Jan 20, 2021, at 7:36 AM, Alvaro Retana via Datatracker <noreply@ietf.org>
wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-sr-yang-29: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=UzYBQkG%2F7WWwviq2NjV6Ws41jzkK6cHXIbgkGMONDS8%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-yang%2F&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vKOEndcJtpxSOMYmSRfeNPcObJygZiXHl7Eo2gn3M9A%3D&amp;reserved=0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I am not
balloting
DISCUSS because this point should be easy to address.

    grouping max-sid-depth {
      description
        "Maximum SID Depth (MSD) operational state grouping.";
      leaf node-msd {
        type uint8;
        description
          "Node MSD is the lowest MSD supported by the node.";
      }
      container link-msds {
        description
          "MSD supported by an individual interface.";
        list link-msds {
          key "interface";
          description
            "List of link MSDs.";
          leaf interface {
            type if:interface-ref;
            description
              "Reference to device interface.";
          }
          leaf msd {
            type uint8;
            description
              "MSD supported by the interface.";
          }
        }
      }
    }


(a) While there is a "type" mentioned, that seems to correspond to the
MSD-Value.  The MSD-Type is not included above.

(b) Note that the MSD is really a pair of MSD-Type/MSD-Value.  The
description
above, even if extended to also include the MSD-Type, seems to allow for a
single pair, where multiple could be advertised per node/link.

(c) The ERLD (entropy-readable-label-depth, for which references should be
included) is advertised in the IGPs using the same mechanism as the MSD:
using
the ERLD-MSD type.  IOW, the separation of the ERLD from the MSD in the
module
is redundant/incorrect.

(d) MSD is a good example of a feature that is common to both the MPLS and
IPv6 dataplanes and should be in the common part of the model, not defined
separately for each.

[Yingzhen]: we had a discussion among the authors, and we decided to remove
the MSD and ERLD status from this SR-MPLS base model.
The consensus is that although MSD and ERLD are related with SR, they’re
not SR specific.

>From RFC 8491:

MSD advertisements MAY be useful even if Segment Routing itself is
not enabled.


We will submit a new YANG module which augments the base MPLS module (RFC
8960) with MSD info.

(2) §3: "Module ietf-segment-routing-common defines generic types and
groupings that SHOULD be reused by IGP extension modules."  The SHOULD is
out
place because the module is either supported or not, if it isn't then there
is
no effect on interoperability because the IGP extension module presumably
chose a different option.  s/that SHOULD/to

[Yingzhen]: fixed.

(3) §3: There should be a representation of the ietf-segment-routing-common
module in this section.

[Yingzhen]: I suppose you mean YANG tree diagram here.
ietf-segment-routing-common module only has definitions,
identities and groupings, and typically we don’t generate separate trees
for groupings. Their trees are shown in places
where groupings are being used.