Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Shunsuke Homma <shunsuke.homma.ietf@gmail.com> Tue, 28 July 2020 16:06 UTC

Return-Path: <shunsuke.homma.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 2F48B3A0E57; Tue, 28 Jul 2020 09:06:23 -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 hYF6DMOyOMpP; Tue, 28 Jul 2020 09:06:21 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 651233A0E54; Tue, 28 Jul 2020 09:06:21 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id d1so10100337plr.8; Tue, 28 Jul 2020 09:06:21 -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=7rZFPcQOjK5Ug9CT/BXYA3rl9S0mNnuojmAOf0KEPNg=; b=coX91zeOyu0EHVgDMp0muvjJSGpscCC2hwjYx9XYKADpwB11c7QLXWJdY2WTyLDAAl ESJfVlruEg5CfxMHjuDJaN6a4K4SpdCx+pDehH8+Lez4AIrijy6TdDOiHKGAOLRUzYO2 JPnijMwgjzhwVyTMGMTHzDHYYIXs4dlusD6QPKzMpNbhDioILtunahNe+RI3P3GVZmCL +OWjVJUAyT+aT4+pLtRBQYcHN9l49ywysW8FesfbvZWYAWP8IbZLVrUcTNc6lwq37XEf iaDsKp3XzirMwHnI+18C//ac9eEQrI9PeaaSbF2L3xrXpOuJRJZpIAe7sbQ3m9CXpj14 RDjg==
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=7rZFPcQOjK5Ug9CT/BXYA3rl9S0mNnuojmAOf0KEPNg=; b=ezfflzoJ1ctAVqPEQbkNJTC/Rg7sqybA4L9fd7JlSXL+em1FoccOaX2kv4DNiUzfZZ +kSg047yUXfZjaewM+OcqZmWg0e50/D9cEpFpak7NgsuafUiGtZ0rtjsaKGFdbS69mwq Y2r9yTQ8DPFct1Pv1Iy6YrXUjSjb8zBhUGXTO+V81Az1QLQBTGYQsaUwRPlrwhb3ksBJ iohmtfyKc2uG3VpJyi7jSxicSUJyjtsdlGN7kq4YWHeIKXXw1wTgc/1Ph/leA/exf2Br Fsc7S5fzZ1JilvcCNVke5JOomEioYWpHNfPGFlK3upZKRMINalH4SaYKNGX3nqV7oQTm bYrA==
X-Gm-Message-State: AOAM530gv4oHoph02VlfD9IydWI2k9MvhPtEh4ISxy3d14vQ9aNMOYxm tVRdYzWMmuSq+vtIUCt8NSW5CcSI57D37hj4mDA=
X-Google-Smtp-Source: ABdhPJyXTvbnd2+cYpExr2AJ8Rfi/nkFeYgPVp1VfQ1/lt7BGIhOmiR5gdz5B0/WvzCrDjpSKDzhR39kxiYY9FSa4IY=
X-Received: by 2002:a17:902:b7c3:: with SMTP id v3mr13864850plz.26.1595952380826; Tue, 28 Jul 2020 09:06:20 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR13MB306697E48ACA918A213E832ED27E0@DM6PR13MB3066.namprd13.prod.outlook.com> <CA+RyBmVix_V9iq9vh6REfqKY6U7Ri75iEda2NzsHn-6CNCYp6A@mail.gmail.com>
In-Reply-To: <CA+RyBmVix_V9iq9vh6REfqKY6U7Ri75iEda2NzsHn-6CNCYp6A@mail.gmail.com>
From: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Date: Wed, 29 Jul 2020 01:06:05 +0900
Message-ID: <CAKr2Fb8pPaqz_kzMUgYc_s6ecAggxo31qLGZrRHdJzBFcbY2tQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.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: multipart/alternative; boundary="000000000000bcd74e05ab829edf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/fCm8dHiat9XW8OBVPeAnkxXlKdU>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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, 28 Jul 2020 16:06:23 -0000

Hi WG,

I reviewed the draft, and support the adoption. The proposal may be a
useful improvement of SR architecture, and it will be valuable to consider
it.

The follows are my comments:
- Regarding scalability, it will depend on how to design configurations,
and I think that there is little difference between existing technologies
and the proposal.  The number of virtual networks which can be built will
strongly depend on the spec/ability of the underlay network.  For example,
the number of available QoS classes is limited by the number of queues
which routers have. Or the size of a forwarding table depends on
performance of TCAM. I think a critical point on scalability is underlay
network spec/ability rather than the nature of techniques/protocols.
- Simplifying data plane structure and its management by unifying several
forwarding mechanisms to SID may be one of advantages of the proposal.
- This extension may be a fundamental improvement, and it may not be
necessary to be tied to usage for enhanced VPN solution.

Regards,

Shunsuke

On Wed, Jul 29, 2020 at 12:48 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Dear Authors,
> thank you for that well-written document. It was a pleasure to read. I
> have a number of questions and much appreciate it if you can clarify them
> for me:
>
>    - how you envision mapping resources to a topological SID, e.g.
>    adj-SID? Would it be 1:1, i..e., a new SID for each resource that
>    characterizes a link in a virtual network?
>    - how granular association of a resource with a SID could practically
>    be? For example, BW may be de-composed into, per. RFC 6003, CIR, CBS, EIR,
>    and EBS. Do you expect a transient SR node to do policing and/or shaping
>    according to such resource information?
>    - I agree, that FlexE is one of Layer 2 technologies to provide
>    predictable, in regard to performance, transport. What benefits of using
>    resource information you see for FlexE? Would an intermediate node manage
>    the FlexE calendar?
>
> Regards,
> Greg
>
> On Wed, Jul 15, 2020 at 4:17 AM James Guichard <
> james.n.guichard@futurewei.com> wrote:
>
>> Dear WG:
>>
>>
>>
>> This email begins a 2 week WG adoption call for
>> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
>> ending Wednesday 29th July 2020.
>>
>>
>>
>> Please speak up if you support or oppose adopting this document into the
>> WG. Please also provide comments/reasons for that support (or lack
>> thereof). Silence will not be considered consent.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jim, Joel & Bruno
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>