Re: [spring] WG LC https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 10 July 2020 07:55 UTC

Return-Path: <dhruv.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 9D9FD3A0EDB; Fri, 10 Jul 2020 00:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 sXPYjPuBDbFX; Fri, 10 Jul 2020 00:55:42 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 277D73A07D1; Fri, 10 Jul 2020 00:55:42 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id i4so5071088iov.11; Fri, 10 Jul 2020 00:55:42 -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=TaWbxCsnzqckfEzSk5cx9GEsQSpLbMA5ySKR5HXX7kE=; b=Um2Qj9xu0JlcOQt//qXLJI0KCTd6eG3rGhjODkahnW9ILHD/N7XREqpUpqTIB9/van fWCHMBX6xGzmFe1W9M+zgUloR2KFpcY9E9WyDyMXHmm0/JJawfVsSErhAHu0kDT4vRs8 DTQRpBtVNfzu6Y3zp6B4XaYS7Bq5fzVgn+J8sdVjoKeXI9VQXqDbnNj6gznniyaWISJ9 HCcu6hAkWfJtV2MxgyY6pnfqoU8xzEIcOmXOoZn3yUYje3YSfFyUf+1Y6H7b1hoLp7bq OuhnYspls9NgkxRbdm9HwSjg2nJu714qDTbRtuDUpMUbI2j/luP9BCWRnoVoNPvBfZdo HuVQ==
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=TaWbxCsnzqckfEzSk5cx9GEsQSpLbMA5ySKR5HXX7kE=; b=OtO63EX/RFYL6kobZKJxI0r2g2eFxONREF/1Yb/YJz5tOft1PKLrbsBQcCUduV24ly gb6HUy+RxS8WsOPPHwEI6wWLwVBIBpp3mX7+hCdfHPFLQXp8LCS66vZfiSZX4d/wFgte 65QFYdUV/lrfdu7XHcVgko6tl5+O3nyBosb8k209kYFjD9CKy6Nb4jKlemJPksFz/zqJ EB/qwUg8zaunTxNsCS7bMLV41ioBkvM+IcIDmi7Pk2B1umFfix2AhBxsnMFFBfuwUIjV lP/RW1217f94RLavGmr0zQNx38YP7KOHVIcWf2saLJjF8phQa34ClnqQgFmWvgElhl1X +Wag==
X-Gm-Message-State: AOAM533NaW0WnPeurCaMmMJTAOadyP0Vbho43YJIU7q3N6/DnZTsvsSj O6VybuuMFHje1iET8bVq+VjrSbuDeidSG3r/cOQ=
X-Google-Smtp-Source: ABdhPJx/B5QSpSqxh9YgRV2O8i1qJ1LdV8l5s9mNdsH4b2COiaDOvWxVY8EGX4PLmJzHL/R9n+sq7naA5dIy2M6I0eo=
X-Received: by 2002:a05:6602:2295:: with SMTP id d21mr46556798iod.0.1594367740197; Fri, 10 Jul 2020 00:55:40 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR13MB3066AF7A192440EBA63E11DBD2940@DM6PR13MB3066.namprd13.prod.outlook.com> <CAB75xn6t_dPeXuh2O8gdc4KWUm7FjZ3N1WVUPEvX2xng=4_yRA@mail.gmail.com> <952978AA-F633-4102-9104-F0D9742A4021@futurewei.com>
In-Reply-To: <952978AA-F633-4102-9104-F0D9742A4021@futurewei.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 10 Jul 2020 13:25:02 +0530
Message-ID: <CAB75xn5TmQ32Xd=5fWJSa=6PEDLAB_vQBnEEMhCXbbDSvr-mRg@mail.gmail.com>
To: Yingzhen Qu <yingzhen.qu@futurewei.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3Na-N8LjWmR1c7bEiXWnelQeTsc>
Subject: Re: [spring] WG LC https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/
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: Fri, 10 Jul 2020 07:55:52 -0000

Hi Yingzhen,

Thanks for your reply, snipping to the open items -

>
> You're correct that SRv6 YANG should be augmenting segment-routing like sr-mpls. This was the agreement between SRv6 and SR-MPLS YANG authors.  Hopefully SRv6 YANG authors will update so in the next revision.
>

I would also encourage you to consider adding some high-level text
describing the relationship between the 3 modules defined in this I-D
and your guidance for SRv6-Yang. A figure could also be quite useful.


>        - Can we rename ipv4-sid and ipv6-sid to ipv4-prefix-sid and
>     ipv6-prefix-sid respectively?
> [YQ]: not sure whether there are other modules using these groupings. Will check to make sure not breaking other YANG modules importing it.
>

I looked in the IGP SR Yang I-Ds as well as searched in the
https://www.yangcatalog.org/ and found nothing.
More importantly, it is normal for other YANG modules to be updated in
such a case.

>        - It could be useful to add a description of why ERLD is read-only
>     in the YANG.
> [YQ]: ERLD?
>

Entropy capable Readable Label Depth - the node-capabilities, and
entropy-readable-label-depth below marked as "ro"

   module: ietf-segment-routing-mpls
     augment /rt:routing/sr:segment-routing:
       +--rw sr-mpls
          +--ro node-capabilities
          |  +--ro entropy-readable-label-depth?   uint8
          +--rw msd {max-sid-depth}?


>        - Can the ISIS YANG typedef be used instead of redefining the
>     system-id in SR yang.
> [YQ]: ISIS-SR YANG will be importing both SR-MPLS and ISIS YANG, so the typedef from ISIS YANG can't be reused since it will cause circular reference.
>

That is not true! Notice the arrows in  - https://sketchboard.me/NCeua6qrZBzV
Also, I made the change in my local copy, and all 3 yang models compile cleanly!

>        - In the grouping sr-controlplane, is it not better to have a
>     reference to the policy rather than a string?
>
>           +--rw segment-routing
>           |  +--rw enabled?    boolean
>           |  +--rw bindings
>           |     +--rw advertise
>           |     |  +--rw policies*   string
>           |     +--rw receive?     Boolean
>
> [YQ]: Do you mean the policy in mapping server? Which is a string.
>

Yes, I assume this policy is the same as -
/rt:routing/sr:segment-routing:/sr-mpls/bindings/mapping-server/policy/name
and thus wondering why not a leafref? If this policy is different
please add more text explaining it.


>        - Target is defined as a string in the yang. You do say that they
>     are IPv4/IPv6 prefix in the context of the I-D. I want to confirm that
>     the string is the right choice in such a case.
>  [YQ]: this is intended.
>

Please consider adding some descriptive text around this.

Thanks!
Dhruv