Re: Next steps on advancing core IPv6 specifications to full Internet standard

Hemant Singh <hemantietf@gmail.com> Thu, 17 November 2016 15:33 UTC

Return-Path: <hemantietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE59012968D; Thu, 17 Nov 2016 07:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Vc9T-fqvJbtb; Thu, 17 Nov 2016 07:33:06 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 53316126B6D; Thu, 17 Nov 2016 07:33:06 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id v78so60215750ybe.3; Thu, 17 Nov 2016 07:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qF6UBI4HVazC5M1vZ/I7+uCe6o6Ok40M8kZPIy2eOMA=; b=nIXcpEgpsfQSlInkb476loHKdex7D3tRrpE16SMTMmOrbRtXaZtZrqcih8u+1+mbGX /szZLfMT/YPVB2500ifGUlCG9zUiHh775TOpbo6ZOIjJQYetumdeLatiZ8jiKIB8nGxd 5MwbxN90dESjQTqyTKwpQVzSL2grMiU+/Ocn77GdVfmst2SRT1T4XvdIsOZjs0fOqtym 0XB1GU4UEfNaOOpkM/o+l8YwxL3UeZJdmEW+904fZRWt4Sg30pUtS8xDc4k8eCvYDi7A WigEjWcQ0jK15cdxcgUdghFhcu8SKNdOaTc6xLgyrid8O5rl6K3sE7g4Ly2n0vmzAy49 toew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qF6UBI4HVazC5M1vZ/I7+uCe6o6Ok40M8kZPIy2eOMA=; b=HObM2Wt8/X7GCxYpoPLVS1SKcKc9PLRW7OxC0Xxzq+0YgzlNOOswLu0GSW/Cg96xqH RGgfWWgP6KgeL7ABDU/edtxr+r7g+y9KEucA/L8z69BmUGx97uqhqV0RGahdEoydpdLV Urca72JlIQbeu+ayacsHRlcBaerE2KRc2ZmyiZILSPso2Pe4SMUm352EbfYXbnKn1rjq JfxR5ckDkIP+Rw6xhulzWkiPJpK/yVaEQR9LlFovUuJ9U3S3IzltTfcK9qdu1gaMx7HJ 6nXtOntWmmUcmFH3Z5SDrV1E7U+6QM99DQlMIdaVnromKbVWHq3Ed6lZqVUz9qd6Qh3p aLyA==
X-Gm-Message-State: AKaTC01ud24SEEzrCS7F9R51oeJ0ghK7lQZQ9P5dBvFnmcCYPrs1Im9fxFpxA5ht8D510kW1OXd5Ew9c3puI1A==
X-Received: by 10.157.17.252 with SMTP id y57mr1599889oty.138.1479396785597; Thu, 17 Nov 2016 07:33:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.15.33 with HTTP; Thu, 17 Nov 2016 07:33:04 -0800 (PST)
In-Reply-To: <85517D4C-488E-4A05-9E2C-5D4604DF69B8@gmail.com>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org> <CAJE_bqczRSZYWC3tDLXvxRMzqnV9nDjYjUddyRHtwfpGEXvm5w@mail.gmail.com> <85517D4C-488E-4A05-9E2C-5D4604DF69B8@gmail.com>
From: Hemant Singh <hemantietf@gmail.com>
Date: Thu, 17 Nov 2016 10:33:04 -0500
Message-ID: <CABdyVt421A8Lsy91TvNRg8w444X04tx-woY3gLj3U0-hxL53og@mail.gmail.com>
Subject: Re: Next steps on advancing core IPv6 specifications to full Internet standard
To: Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c19204ae331f8054180e7f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/uWwfodTgewOdRl06ORzDQa0lCQo>
Cc: 6man-chairs@ietf.org, IPv6 List <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 15:33:08 -0000

On Thu, Nov 17, 2016 at 8:55 AM, Bob Hinden <bob.hinden@gmail.com> wrote:

>
> There doesn’t seem to be an evidence that there is an interoperability
> problem.
>
>
A SR deployment uses source routers from different vendors.  One vendors
uses "add an EH header" while another uses the encapsulation method to add
the SR info  The intermediate routers have to read the encoded SR
instructions for forwarding.  How is the intermediate node instructed to
decapsulate and read vs. look at an added EH by the source?  Maybe SR deals
with this issue and if so, please let me know which of several SR I-D's
cover the details.

Likewise, Inband OAM has mixed router/switch vendor deployment.  One vendor
uses add/delete EH while another uses encap.  How are all routers/switches
instructed to use which method?

When folks get a chance, could they please also reply to my questions on
Inband OAM and SR in earlier emails from today.   It is useful to the
mailer to articulate what show stopper problem did one encounter that one
could not use encapsulation.   Only once such issues are closed, one can
start the other document that would cover pitfalls of add/delete EH by
intermediate nodes.

Thanks,

Hemant