IETF Logo Mail Archive

Re: Question on draft-ietf-6man-segment-routing-header-04 (not needed PHP-Style behavior)

Shay Zadok <shay.zadok@broadcom.com> Thu, 02 February 2017 07:20 UTC

Return-Path: <shay.zadok@broadcom.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 940021293DA for <ipv6@ietfa.amsl.com>; Wed, 1 Feb 2017 23:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=broadcom.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 H3yhgx_lBWZv for <ipv6@ietfa.amsl.com>; Wed, 1 Feb 2017 23:20:04 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 42CF6127735 for <ipv6@ietf.org>; Wed, 1 Feb 2017 23:20:03 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id b65so76143376wmf.0 for <ipv6@ietf.org>; Wed, 01 Feb 2017 23:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2A8Sgb+AGWdBnX4wQWTMHGwJOs13I8eigVcCwWftQvw=; b=YrDLM9vZS6+KsPS8R5boR9F1WzOVYNwiMyt37oXVB+/u8CbKEun6UHrOEgt9JFjRv+ R2u0UhQ26uw+ouWuFIIcuiStKg6lPXUe1kuVKI3AWXp/OJ5rQcXhKfWOAVyBerpypK5d HXDPbmfwB4Yb/XrDVo3qplEHx2kJ7PFULALds=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2A8Sgb+AGWdBnX4wQWTMHGwJOs13I8eigVcCwWftQvw=; b=TFMtfoBZ90hps6gn9fsD3vIGzoIUtSkI1Crk/8jaEX1jnF2OcV7S/AkBzroXyMsLli WOblLsqhfuR6/AXUIHL+fO6eHc03K3HmcqQ5lqDdnVub5AlDLg9f3iM4W5X2tVif3OnB xMBZKKpCY9s8KJpJBPlN1vq02efZXK/5vzXNfaaqjqJgZS1v34/C2f6Zp4wOxN88Afua 6aYm0oVgRy2mLkAziIG0GsNc/W6jkHOjIotmSYF3ZMonsgVgcJFm4GLGW5Nd7pfGINXo W6Si4CkeqUwkYqobIczC0rEWJLqae14fCGqOOaPMTn5kovPnQgBqiM9oqZbkgZ44q+gH 0fbw==
X-Gm-Message-State: AIkVDXLNWS2GmKtnVTMb1e3vx+uyIUzYvE7rX9KsvwLbf9JfGk/s5b+PurC7rAgjWp1MGVHLIaaGSWUnBshsIOrw
X-Received: by 10.28.188.9 with SMTP id m9mr5994872wmf.79.1486019998024; Wed, 01 Feb 2017 23:19:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.193.6 with HTTP; Wed, 1 Feb 2017 23:19:57 -0800 (PST)
In-Reply-To: <4B338C4A-FCBB-4F80-8DDF-F645C6B38FD3@cisco.com>
References: <CA+X6GCQNLUfxPPOHC_XBU05-tsdb39CJwcigWiQ28pEL5t=FBw@mail.gmail.com> <4B338C4A-FCBB-4F80-8DDF-F645C6B38FD3@cisco.com>
From: Shay Zadok <shay.zadok@broadcom.com>
Date: Thu, 02 Feb 2017 09:19:57 +0200
Message-ID: <CA+X6GCR=Y98W8Qnm5msVu-3RYARvgS9x9CDck5oHB_jgrozDCQ@mail.gmail.com>
Subject: Re: Question on draft-ietf-6man-segment-routing-header-04 (not needed PHP-Style behavior)
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Content-Type: multipart/alternative; boundary="001a114b24d81d0fce054786fec7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QngDYS-e-puhIc7XaXplJ-D3eWY>
Cc: "ipv6@ietf.org" <ipv6@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: Thu, 02 Feb 2017 07:20:05 -0000

Hi Stefano,

Thanks for clearing.

I just saw routing-header-05 changed from "insert" to "add".
Which means full tunnel add/remove, and coherent with no need of C-Flag.

Best Regards,
Shay


On Wed, Feb 1, 2017 at 10:12 PM, Stefano Previdi (sprevidi) <
sprevidi@cisco.com> wrote:

> Hi,
>
>
> > On Feb 1, 2017, at 12:34 PM, Shay Zadok <shay.zadok@broadcom.com> wrote:
> >
> > Hi,
> >
> > As 'Clean-up flag' is omitted from segment-routing-header-04, does this
> means that no need to support PHP-Style behavior in the segment before the
> last one?
>
>
> the clean-up flag was used when an SRH was “inserted” underneath the IPv6
> header by a transit node. In order to be able to deliver the packet without
> the SRH you needed an indication for the penultimate segment in order to
> remove the SRH prior to send the packet to the destination (last segment).
>
> The behavior described in draft-04 is different and consists of the
> addition of both an outer IPv6 header and an SRH (i.e.: encapsulation
> instead of insertion). In that context, the PHP behavior (cleanup bit) is
> no longer needed.
>
> s.
>
>
> > That is, last segment *always* get the SRH header.
> >
> > Thanks,
> > Shay
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>

v2.23.0 | Report a Bug | By Email