Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Dhruv Dhody <> Thu, 20 August 2020 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DE3F3A0A43; Thu, 20 Aug 2020 07:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MUUIyjw7TzzI; Thu, 20 Aug 2020 07:08:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7AA03A09AD; Thu, 20 Aug 2020 07:08:29 -0700 (PDT)
Received: by with SMTP id c6so1699587ilo.13; Thu, 20 Aug 2020 07:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f5SFo6YDc0eoBzqDfJkYQj/efy46NDH08spevcDezp8=; b=EWzmG9sQhjtzXQYLA+oSPuiLt8cW46gFBZbhulXhcMg58GbRL0GHc4WpDpyFsh+R2i TmyIh5nOn9i1r0SaT+W9ZSIM2xK29u3rbZMWUglS4Tv2HUXpJrw7OhtskIJ2arVu3tdW iDXNyOqx3I/JUhZi299VzBncCdVgFhfcfb7NRhBCVkdJCINT5FoTQUSufy/C1Pm7MVh2 56Btq0EsanpoFpSJwdG1y+wtjyVt9UKlc75JrbLRCJueryN1hujXHFE6Gum0/jm0fHZ8 qKGb6fvru48lXyVP8+QwWr37ayhDtzKKwXYOlb3tsPkF8kGi3fKlnpDcricXiWhfV4TG wVow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f5SFo6YDc0eoBzqDfJkYQj/efy46NDH08spevcDezp8=; b=LKsHi6yXF1k8K/R6WqtBrYdeOySRtpw9B2wfgXljTUv6vbAf7o9TAdCmylhKJ7oq3o 6SnmVpJub7l6zqNowsnL5FF4rNNwupAZURQwPKyBRRxxpx7L2mfiv9/mgQvenAcVyFOP L+GU7FCJwkBUNg4pUzom027eB60zp0SnfyvNn1LlseJrSCHgbDScneo2Yx0VYhZrlE+B 3SvYjS66Heh1E+6DVPI5fNLQ6kmUU14VvVgMT7/W/dp1HnlHDHhPa585whhoS8qHmzDX +oDaLNqj7lUPhyawBRLDfrkNbA+lJl7quaUourKtMdYJ8jmFdsYQFksfxdso0Awbxws/ Sn3g==
X-Gm-Message-State: AOAM530yLAqDR2rOO7iPNvcIo9v8zY0d/9WO0G/UbQKAoHh4NZVQSp3y axmAx4j7DBlyVgD9OorPFVvWh/xEZ0lboFOw2Ml7I2o9m6wfeQ==
X-Google-Smtp-Source: ABdhPJwV4yOQDDvuR4UBACI3oqz3hotj3ztuE9v2vo/lP7d5QtQwfsgQj3P0/2wIpWfwmauPR+DNLGW/Ms2i3ncFBD8=
X-Received: by 2002:a05:6e02:1352:: with SMTP id k18mr2769031ilr.276.1597932507838; Thu, 20 Aug 2020 07:08:27 -0700 (PDT)
MIME-Version: 1.0
References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Dhruv Dhody <>
Date: Thu, 20 Aug 2020 19:37:50 +0530
Message-ID: <>
Cc: "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Aug 2020 14:08:32 -0000

Hi WG, Authors,

I support adoption.

Looking forward to changes as per the discussion in the other thread
started by Joel. I found a few things that can increase the
readability of the document.

- The document doesn't use normative keywords of RFC 2119 (RFC 2119 is
in reference somehow still). I am wondering if section 3 and 4 could
use them esp section 4.
- Section 6, I feel we should at least add a reference to Section 8.1
of RFC 8402 [ ] to
provide a helpful pointer. Can we add some text regarding the context
labels - that they do not impose any security issues with a suitable
reference (provided that is true :)?
- Can we expand "externally visible forwarding behavior", the
reference to draft-bashandy-rtgwg-segment-routing-ti-lfa but I don't
see that term being used there
- Section 5 could use an example to describe the concept clearly

- Expand sids in abstract
- Expand SRGB on first use
- Should we state it clearly that this document is applicable for SR-MPLS only!
- Suggest to use RFC 8402 notations for the all sids: Node-SIDs,
Adj-SIDs, BSIDs instead of node-sids, adjacency-sids, binding-sids
- Section 2, not sure about "SPRING enabled on each node"
- Section tile for 2.1 and 2.3: I am not sure about the terms
"node-sid explicit paths" and "adj-sid explicit paths" where the later
is actually a mix of node-sids and adj-sids. Perhaps rename them as -
section 2.1 to "Node protection for explicit paths with Node-SIDs" and
2.3 to "Node-protection for explicit paths with Adj-SIDs"?
- Figures, add a legend stating what does the values "10", "30", "60"
on the links mean - it is clear that it is cost, but would be good to
be explicit.


On Thu, Jul 30, 2020 at 5:54 PM <> wrote:
> Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked for WG adoption.
> Please indicate your support, comments, or objection, for adopting this draft as a working group item by August 20th 2020. (*)
> Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this.
> Thanks,
> Regards,
> Bruno, Jim, Joel
> [1]
> (*) 3 weeks to account for the IETF meeting week and the august/summer period.
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> spring mailing list