Re: [Rtg-dt-encap-considerations] Minor comment Re: I-D Action: draft-rtg-dt-encap-00.txt

Erik Nordmark <nordmark@sonic.net> Mon, 09 March 2015 22:34 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: rtg-dt-encap-considerations@ietfa.amsl.com
Delivered-To: rtg-dt-encap-considerations@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538441ACDA1 for <rtg-dt-encap-considerations@ietfa.amsl.com>; Mon, 9 Mar 2015 15:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3unUnccgJfUT for <rtg-dt-encap-considerations@ietfa.amsl.com>; Mon, 9 Mar 2015 15:34:47 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D3A1A909F for <Rtg-dt-encap-considerations@ietf.org>; Mon, 9 Mar 2015 15:34:47 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t29MYjnD012610 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Mar 2015 15:34:46 -0700
Message-ID: <54FE2005.5030704@sonic.net>
Date: Mon, 09 Mar 2015 15:34:45 -0700
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Joel M. Halpern" <jmh@joelhalpern.com>
References: <20150309202017.22852.40860.idtracker@ietfa.amsl.com> <54FE04A8.30203@joelhalpern.com> <54FE08D4.7060804@arista.com> <54FE09BC.3030500@joelhalpern.com>
In-Reply-To: <54FE09BC.3030500@joelhalpern.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYXcbRESaSMmdb4a/WTPFjrTJ0lULYoL9ITr2CRmto6Igu2v6YN90ZofxnAlcnWISy/px13OVnynMvcFZS+KwtL
X-Sonic-ID: C;BtbPfKzG5BGEJO8Jj30JFw== M;lgMNfazG5BGEJO8Jj30JFw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/yi1wLzHNuyIWyRtQ3mWsHQ4-VJ8>
Cc: "rtg-dt-encap-considerations@ietf.org" <Rtg-dt-encap-considerations@ietf.org>
Subject: Re: [Rtg-dt-encap-considerations] Minor comment Re: I-D Action: draft-rtg-dt-encap-00.txt
X-BeenThere: rtg-dt-encap-considerations@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <rtg-dt-encap-considerations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/>
List-Post: <mailto:rtg-dt-encap-considerations@ietf.org>
List-Help: <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 22:34:49 -0000

On 3/9/15 1:59 PM, Joel M. Halpern wrote:
> The text reads:
>    o  SFC carries service meta-data which might be unmodified, but talks
>       of a ttl for loop avoidance which is modified for each hop in the
>       service chain.
>
> Which seems to imply that we expect metadata to be unmodified.  I 
> found it quite jarring.  I did understand the point you were trying to 
> make. I think that SFC, like BIER, expects (or at the least is 
> designed to always be able to allow) header content to be modified en 
> route.  So putting SFC in the middle of the list does not help show a 
> spectrum.

How about
     SFC carries service meta-data which might be modified or unmodified 
as the packets follow the service path. SFC talks of some loop avoidance 
mechanism which is likely to result in modifications for for each hop in 
the service chain even if the meta-data is unmodified.

    Erik

>
> Yours,
> Joel
>
> On 3/9/15 4:55 PM, Erik Nordmark wrote:
>> On 3/9/15 1:38 PM, Joel Halpern wrote:
>>> The overview description of SFC implies that SFC expects metadata to
>>> be unchanged edge to edge.  In fact, we expect service functions to
>>> add metadata, and possibly modify some metadata.  SO saying that it
>>> may be unmodified, while technically correct, seems misleading.
>> Where do we say that? I think the draft says that some SFC data will be
>> modified (with an example about loop suppression). We could make that be
>> more open-ended. Main point is to show the range from NVO3 (no
>> modifications along path) to BIER (every BIER router modifies the
>> bitmap) with SFC being somewhere in the middle with some modifications.
>>
>> Thanks,
>>     Erik
>>
>>
>>>
>>> Yours,
>>> Joel
>>>
>>> On 3/9/15 4:20 PM, internet-drafts@ietf.org wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>>
>>>>          Title           : Encapsulation Considerations
>>>>          Authors         : Erik Nordmark
>>>>                            Albert Tian
>>>>                            Jesse Gross
>>>>                            Jon Hudson
>>>>                            Lawrence Kreeger
>>>>                            Pankaj Garg
>>>>                            Patricia Thaler
>>>>                            Tom Herbert
>>>>     Filename        : draft-rtg-dt-encap-00.txt
>>>>     Pages           : 37
>>>>     Date            : 2015-03-09
>>>>
>>>> Abstract:
>>>>     The IETF Routing Area director has chartered a design team to
>>>> look at
>>>>     common issues for the different data plane encapsulations being
>>>>     discussed in the NVO3 and SFC working groups and also in the BIER
>>>>     BoF, and also to look at the relationship between such
>>>> encapsulations
>>>>     in the case that they might be used at the same time. The
>>>> purpose of
>>>>     this design team is to discover, discuss and document 
>>>> considerations
>>>>     across the different encapsulations in the different WGs/BoFs so
>>>> that
>>>>     we can reduce the number of wheels that need to be reinvented 
>>>> in the
>>>>     future.
>>>
>>