IETF Logo Mail Archive

Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Uma Chunduri <uma.chunduri@huawei.com> Fri, 13 April 2018 20:32 UTC

Return-Path: <uma.chunduri@huawei.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0BF127978; Fri, 13 Apr 2018 13:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mcNEU_tOqwfb; Fri, 13 Apr 2018 13:32:43 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 58989129515; Fri, 13 Apr 2018 13:32:43 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 22BC3D7A73901; Fri, 13 Apr 2018 21:32:39 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 13 Apr 2018 21:32:40 +0100
Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Fri, 13 Apr 2018 13:32:34 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Mickey Spiegel <mspiegel@barefootnetworks.com>, Tom Herbert <tom@herbertland.com>
CC: Greg Mirsky <gregimirsky@gmail.com>, NVO3 <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, Service Function Chaining IETF list <sfc@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [sfc] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
Thread-Index: AQHT01Rv/8zdN25zjECovFVjh39kLaP/JHDg
Date: Fri, 13 Apr 2018 20:32:33 +0000
Message-ID: <25B4902B1192E84696414485F572685413553740@SJCEML521-MBB.china.huawei.com>
References: <ff0c9182d1f14ec48b352e41fedaf58e@XCH-RCD-008.cisco.com> <CA+RyBmUNHcQZtTGJj67V=DqPkwV6GXWDUQJGjwT7ODEFg_QQFA@mail.gmail.com> <CALx6S36ojk0z+iOhNhFqF2A+acXC1=xHPEN7G0Y_9+itC+WiGQ@mail.gmail.com> <CACYmcDqd2gwUTmjj-BssB1Bh7EAVi6v_Uu6Qq9XXd2RbdMnGGw@mail.gmail.com> <CALx6S37aig+JJ8WPgC6NDeNExJ_qS9LZweSL2TOgD1EPqZRwTQ@mail.gmail.com> <CACYmcDqVzr9y-LyUzJPs98mrmGZynUCUiPwepNBQpsKdyweyPQ@mail.gmail.com>
In-Reply-To: <CACYmcDqVzr9y-LyUzJPs98mrmGZynUCUiPwepNBQpsKdyweyPQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.216.254]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F572685413553740SJCEML521MBBchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/_uvoKTzLeBoDRF-1wszsdX7V6Q4>
Subject: Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 20:32:47 -0000

I am also wondering if hop-by-hop options been considered for this
application? Their interpretation in the network is unabiguous and
they also have the advantage that the work with any IP protocol or
encapsulation.

IPv6 hop-by-hop options has been considered. See
draft-brockners-inband-oam-transport-05. This has not yet been
broken out into a separate draft.

[UC]:


        “The
   Segment Routing Header (SRH) for IPv6 offers the ability to transport
   TLV structured data, similar to what NSH does (see
   [I-D.ietf-6man-segment-routing-header]).  In an domain where in-situ
   OAM is used, insertion of the in-situ OAM data is enabled at the
   required edge nodes (i.e. at the in-situ OAM encapsulating/
   decapsulating nodes) by means of configuration.”

I see SRH TLVs are being used for IOAM data. This is fine at the insertion point at the edge node as mentioned above,
but can you help explain how IAOM data gets added along the path towards the egress ? (yes, if you are in hop-by-hop EH, like SRH ).
Only way you can do this is by slapping 8200 encapsulation at every node? Is this correct ?

--
Uma C.

v2.23.0 | Report a Bug | By Email