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

Hemant Singh <hemantietf@gmail.com> Tue, 22 November 2016 03:22 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 9C069129490; Mon, 21 Nov 2016 19:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ctgJm7QtG_dw; Mon, 21 Nov 2016 19:22:22 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C9C401294E1; Mon, 21 Nov 2016 19:22:22 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id w63so5630664oiw.0; Mon, 21 Nov 2016 19:22:22 -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=SG4/CcPwxbqvGK4KkmXBOXnmTn5YPURhpEnPYr8aoRU=; b=Oex1AADL+TbsXU8VRoD7hLuFUUlZfuhH2gY4dSAHMTn/BsIHG4MY41ZFx/8pzQWJdc IN0YRBcuST9Ksadhz0L+Mk3xFdX321uVmzkM6ULTMy8sNi/3rWZjslZvcsAogMFhxORb CmtMomUEesg8gvAbakZQDfV/aW44rhwolYtmsgojTU6XKajCQKgGXwavDdFOaZMPo3w3 INBZGWtRjSI03KkGWmgskQi2d/PZeztYqLGVBEVIkMZdTI/xSPi0ahsaE5X37B/c3O9Y vzImndJt1GEoz/99y6WeLqRHjK0t1ZPXkKgJfcCNPUKhWgQMxp+d5R1NxE//18BBzS9X nREg==
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=SG4/CcPwxbqvGK4KkmXBOXnmTn5YPURhpEnPYr8aoRU=; b=SqjzRdiOvqIVylC5UzbiBqZm6DpJzRZ2GkWn+blZW7f7j+wbfG98hcVq/j9smvRNSS 4RAv/0+284+0bW7H8g4QMr7vnkf4ekWQ7t3uHFuOe33/RcBoKU/MFcQWomTvH4TI3FdM VdHxjdEr+mtg4UE3wJRlduf1MIbvLSnA4qSFVVgEv2RdQaHKravhZtpMO8n0Zlkq0NG4 qXWKIBnvHp0LMA+hCMd/8T1k7LpgWgDdswLotbOA1F0Yr85NwfinIJaQ29Ktt4MeebPO 1XE/GJe7WVenEMjyuSmP1sjTII+hlMhSLpv4X3VJpOhxcbS6YzkF8sivDJnkCGSWdGsg Tzyw==
X-Gm-Message-State: AKaTC00N5PrkhyWm6kX7RNWT0b8V+wC1130+yUaogDROsVkmKJjSlws+03+wB2G1p1HVXZ0BwrD2XHEohuSVkA==
X-Received: by 10.157.52.100 with SMTP id v91mr12268691otb.5.1479784942049; Mon, 21 Nov 2016 19:22:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.15.33 with HTTP; Mon, 21 Nov 2016 19:22:21 -0800 (PST)
In-Reply-To: <CALx6S34VKLPctnMrKQB+AxYFKHzDnYv9woLdqCbtYXgJ7sLy+w@mail.gmail.com>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org> <CAJE_bqczRSZYWC3tDLXvxRMzqnV9nDjYjUddyRHtwfpGEXvm5w@mail.gmail.com> <85517D4C-488E-4A05-9E2C-5D4604DF69B8@gmail.com> <CABdyVt421A8Lsy91TvNRg8w444X04tx-woY3gLj3U0-hxL53og@mail.gmail.com> <CALx6S34VKLPctnMrKQB+AxYFKHzDnYv9woLdqCbtYXgJ7sLy+w@mail.gmail.com>
From: Hemant Singh <hemantietf@gmail.com>
Date: Mon, 21 Nov 2016 22:22:21 -0500
Message-ID: <CABdyVt4dm1bA4W_6ZsL_n4xF4J4Yc4eOGmPNpsn6-C-0ojPX5Q@mail.gmail.com>
Subject: Re: Next steps on advancing core IPv6 specifications to full Internet standard
To: Tom Herbert <tom@herbertland.com>
Content-Type: multipart/alternative; boundary="001a11416e3ed09e620541db4760"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3bpBFERQlhvf5CACkUt5D4E4HkA>
Cc: IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, 神明達哉 <jinmei@wide.ad.jp>, Suresh Krishnan <suresh.krishnan@ericsson.com>, 6man-chairs@ietf.org
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: Tue, 22 Nov 2016 03:22:24 -0000

Tom,

Please see in-line below against "<hs>".


On Mon, Nov 21, 2016 at 12:44 PM, Tom Herbert <tom@herbertland.com> wrote:

Rather or not encapsulation is used, the SR EH would be an extension of the
> outermost IP header. Intermediate routers would not be concerned with
> rather the packet is encapsulated except when they are the terminal point
> of the encapsulation (need to decapsulate). So the SR EH is processed the
> same by intermediate nodes whether encapsulation is used or not.
>

<hs> Agree.  I thought intermediate nodes in SR could add a new SR info and
then another layer of encapsulation is used.   It turns out, this is not
the case.


> 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?
>>
>> This is inband OAM in an EH or within an encapsulation?
>


<hs> Inband OAM in an EH.  If encapsulation is used each node in the path
of the packet adds a new IPv6 header followed by a Hop-by-Hop (HBH) EH.
The EH includes OAM data.  Now if encapsulation is not used, each node adds
a its own EH - at least this is how the FD.io Inband was described to me.
Thus all nodes have to be instructed how to add the OAM data using
out-of-band mechanisms such as DHCPv6.


> Note that the suggestion to use encapsulation is not normative, it does
> not provide exactly the same behavior as inserting EH would (for instance
> ECMP handling would be very different). I think the interaction between EH
> and encapsulation needs to specified as part of the encapsulation, for
> instance the question of what EHs must be copied from the packet being
> encapsulated to the outer packet will need to be addressed.
>
> <hs>Hmm.  ECMP is used when multiple paths exists to a destination.   If
> each node in the packet path uses encapsulation, the new IPv6 header added
> by the node, still has the destination identical to the destination when
> the packet was sourced.  So why should ECMP be impacted whether
> encapsulation is used or not?
>

Thanks,

Hemant