Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method
"Ackermann, Michael" <MAckermann@bcbsm.com> Mon, 13 February 2023 16:42 UTC
Return-Path: <mackermann@bcbsm.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 BDCF4C14F5E0 for <ipv6@ietfa.amsl.com>; Mon, 13 Feb 2023 08:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=MAckermann@bcbsm.com header.d=bcbsm.com; dkim=pass (1024-bit key) header.d=bcbsm.com header.b="nstt9Vz6"; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com header.b="H7+5IyI7"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNWGSLYL-I1E for <ipv6@ietfa.amsl.com>; Mon, 13 Feb 2023 08:42:30 -0800 (PST)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 686D6C14F727 for <ipv6@ietf.org>; Mon, 13 Feb 2023 08:42:30 -0800 (PST)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 8FB74C0AFF06 for <ipv6@ietf.org>; Mon, 13 Feb 2023 10:42:29 -0600 (CST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ZIXVPM1670e2ded26; d=bcbsm.com; h=From:To:Subject:Date; b=hR71UMd2SgThJyH8ZpmlRtgvMKmDgMisL8cSLShbWtdMeV/v+mrbiBkNV0tvNlkP xX3NUD9w1jxLWxuYeEWD0jhtHTSxlyfqyZsoDr894oK2+xKxj6t2KJMeyYrkJ9 dXtZbd5a/ObIdvlgvEIyPzrbRi1NeOsCEyimeMgRe6Pww=;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.com; s=ZIXVPM1670e2ded26; t=1676306549; bh=fYLxsTTVCl3ZcXsPYtfmB7flitXk10yy5Aa2f3tDMOQ=; h=From:To:Subject:Date; b=nstt9Vz6Ih9Z1ev6wJy0cgCS600pkmdnuGAsuZS3xzU7gtHLiap2YuW6l6t/xb6Sv 6HoQCieEr0bJpQFPcAbMcamYD5waAJvJNPTXsBIxL2w+TeGP+omgzxborqzL2za0pV Voqxkdv8j7hPibedjj76em+qVTOVvmPC3FbCWalE=
Received: from imsva2.bcbsm.com (inetmta04.bcbsm.com [12.107.172.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.z120.zixworks.com (Proprietary) with ESMTPS id 4EAFA4180DC1; Mon, 13 Feb 2023 10:42:28 -0600 (CST)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D1296FE07C; Mon, 13 Feb 2023 11:42:27 -0500 (EST)
X-IMSS-DKIM-Authentication-Result: imsva2.bcbsm.com; sigcount=1; dkim=pass(1024-bit key) header.i=@bcbsm.onmicrosoft.com state=0
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F9B4FE079; Mon, 13 Feb 2023 11:42:27 -0500 (EST)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (unknown [104.47.70.101]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Mon, 13 Feb 2023 11:42:27 -0500 (EST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DYwP6d9gpdB8iyrpWFOGUMQniOWFweQ6achlvHTPcaFU9t6fW1SRmc3dTW7Z415RyqvWewVneoTgvtZ1DpJzemF7IsEv/BOhk83tZwdvgRN5P+F2Aee6mJgtaZxKGoiGyJJZCUVpwdI3yiAVpbMUtlLy+Vy49uuTK0EN7CFOiX6Cow3G6E0sAXyBVNE9obYOMu7MOrizksr6xs943/t6K8sr6KGiguvR9pbVReQVS3Q1c5qphLLAn0k4VX0bRo+4HfsGHYJ9Hli4AWstKZW76ItIMkX44oxYhySRWqIpkQ7FL+OLzrh0MIRCF051m7fETmrgfICSWEz632Xp9ARymw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wzxqHtkmui/3Bb15QKxBmVzh5RI4ZKmH3edNzLlGoqA=; b=EGROpdbTtzxpkXCuzNRJjEwtzwxb66gUfT9wFEbuMhwZcMgKk4s4hY9hsksWzWEjwtVKZVwvOnvH/qR07cDYlfnWRPc7gkNbw4zkkHKVb0dpVCSaKKE2CHS29gDupcB8NawoEmLVJautqgIXLRVIi+PIoCTgtlxZ+Ou3fUsgyuAob2YNbiOjlMguTo48WSANDLjiIsgATccLowIC71e1M71Caz6oSbGe0L7YsLnZCeSKmzyDTz3r8/LHJXrF9lfYaccG6slgzI8ygkPxr02T2w25v/LuLbb/nrLxRCqTGoJ8NpBNhGKFaIR4mN65oWHaOkTGeaXILpLux1Uc0rXUtg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bcbsm.com; dmarc=pass action=none header.from=bcbsm.com; dkim=pass header.d=bcbsm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector2-bcbsm-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wzxqHtkmui/3Bb15QKxBmVzh5RI4ZKmH3edNzLlGoqA=; b=H7+5IyI7zztCyp8/AfDEDfymQ0Yb511SEWVV+9XsRLEXrCGdz8K84i3tTxcMr1WAPMJ5wPvK9JVRpMlWaxBtbW5RiziC8mq4+q/cRm9Cjzw0vs8zu4M2eOjdRYr4NoilGfM5gn0aF+a7Cvjh8EO6tYBU3mf17S5YY6rSsKT8Leg=
Received: from CY8PR14MB5954.namprd14.prod.outlook.com (2603:10b6:930:61::22) by CH2PR14MB3771.namprd14.prod.outlook.com (2603:10b6:610:64::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24; Mon, 13 Feb 2023 16:42:25 +0000
Received: from CY8PR14MB5954.namprd14.prod.outlook.com ([fe80::f70a:7140:6164:13b]) by CY8PR14MB5954.namprd14.prod.outlook.com ([fe80::f70a:7140:6164:13b%6]) with mapi id 15.20.6064.032; Mon, 13 Feb 2023 16:42:25 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, Joel Halpern <jmh@joelhalpern.com>
CC: 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
Thread-Topic: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method
Thread-Index: AQHZNp9951uZMJaW50GET7ZqjT9/8a7JcgsAgAOeagCAABaBsA==
Date: Mon, 13 Feb 2023 16:42:25 +0000
Message-ID: <CY8PR14MB5954E72CBB4DB29B34612866D7DD9@CY8PR14MB5954.namprd14.prod.outlook.com>
References: <c51e4a3f-5e6e-5386-4e6a-23709d52c1fe@joelhalpern.com> <CABNhwV3i5myrZzN+656Qwg-wxJS5yPypUgOavw1oL250drS4UA@mail.gmail.com> <abfc9684914c46d0bd9b09e28a1c8067@huawei.com>
In-Reply-To: <abfc9684914c46d0bd9b09e28a1c8067@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=bcbsm.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CY8PR14MB5954:EE_|CH2PR14MB3771:EE_
x-ms-office365-filtering-correlation-id: 5cf2f43c-2389-4064-cf56-08db0de149a8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7d6VvAemtJFTCSPXUA7JDIePEXFWz2B/jekc8O56s1x+9TGxyH3FA4MKmDgLSD3LOsKEkHTa4bUaQzTTNxUuFH3TlXsecoQjM6ryGFhUnW6LKvxJNIgy+m7gkApl3cKwDzHS42uLaZxxAgJr//QNXCoJWfnbOn0icmKO/bp2Co1bXZ3c26m+vt6qoMjtRyVym3+BDJ2JD76ww3JbLW6HwYvVofKbuIHdkR5YaD9XHJ+nztfPQFfbawmWupQ9oaZGz0b25HnwQt9q88Vd/1TcF/vK9ycUEUZwayuo4RMhCps99b9Mt6Zpgd7INZnVZw77fsdnHEMH2hd68o8Ff9wHRtCKGnN5Sk7sg9e4YMefDDhmPc/rrGzcBDnssAkWzxr4waG+GLuW491Z2DTHp1ml8Zsg2JDHHsNIAlsTosoo+NsDL4bMgEva0JmO1zT1/lAwkWNjuHrwBp35tftdW7m69oDLx4Uq3HIm79/V6zgfKQvKeQoc+tsG8yMf5QEFrm0wP3Hs0PA5ff7ftcbAl7dIOj1Jju0LJYM2rihpB1y2HELfX6BcnftFDKJ20T7JliwoBC4tsB6wTnzmyvslFtk50Q4XC/2bMIzKkQNkjZi344Ed4lNVYs2O00YT6j3kq4vBKDAVKGg5YXwGyjOYBZNb9T7TJZ0KrXIIhYxQardvkZKAlEvsY9FD23LS2j5z8oZHr2ayguV1NbEkHwQLIhBjba5q6xAJYgd84f6C4YE0HPU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY8PR14MB5954.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(366004)(376002)(136003)(396003)(346002)(39860400002)(451199018)(83380400001)(7696005)(53546011)(26005)(966005)(71200400001)(33656002)(2906002)(6506007)(40140700001)(166002)(110136005)(54906003)(38100700002)(99936003)(38070700005)(64756008)(66946007)(8676002)(66556008)(76116006)(9686003)(66476007)(4326008)(478600001)(186003)(66446008)(52536014)(122000001)(8936002)(86362001)(55016003)(41300700001)(5660300002)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: F1MJd8fbwl1z6xiSvqR2CTXwiIsZsyGbkvJj6yXXTuRwDJH86IyQuCTlxZvri5SVYDW313k7U1D+C3Op3l6zgqbkx5eQAXx04FfxhlDgX2aqyX57LXB7VoUgH3Z8Xd4DLCegtk+Z0xt3qHFvW5wQVGeCjxQ04RjrKledE3m2Vg8y/EsNp52gIXsMNUJSapvyT1imgklpB7GwBOWkheDW8m0XQZQoXT3wRE1KRqf5HSwVjR/dCdISaT8eHOl0/KYouIYETldkKRKbKXvd//f32iOrQqb7DR1sXUOO7Gf0RJHtkTKOq4HznUF1etM6QcIzVRVuF1bYj32g5woblUrtPl8KiEHziYmx8Mub4ayd0K26095hogW2dvSh5qeEVNhzkD2HmJtZZ5ztraoq2IgK3EJa/WITG3E+VvDZ696PbcKGsctAqqgCf5OItJbRCmccCDqqXl+YT0AkEuea4cur2rt8e5pP39B+ImDbh7OpUs/UYj4QqNQfQoQhiuKUDuxl+yAVoBwnodAswcxWtnkgLiw55M77JS/aQOsljQONeXvw40dZwRNawrSU17r7xBN5GLPDDyzI9BjFplvKjuErWpC4P0XJI8iYrJdK6uECzmwOrjFzsUR7LE8564PvPv8xM3L8YeZrZuvwQSWoKT7gn2Rn0BC5MRLo2qsDwARHMcTxyWqvfqk/7/u91Z9TO3H1c1TTuAW+viPu/L6iUO+fehOgxmiS8lcphwU7beeEi7PSBeqB0WOy52utRHDgSe3yVvQwn8fral+AQBtqpvvhF4WK6oUm9lOvH4XAzSjrYk7DsKSx6cKoICs0pPZ8NFyoSssnU0POdh+TcYn7wZenVBsxevzj7EqyQVXUvGlQ73zC6rW1YYX7dPodcNvDiAyBxnBM6m7bG+ZLYs5Aba11NOD1P7wbGe3nXBMWC93OojKY1Np3cv3sbttgZbcdIhLIxc5fykTw13/PwbDFC0ovaJh5aKio9vnjObxnmUDwkhp5O4SkVeW05MkN8dLKBmTx6Q4tqIn3cUmQeO21tkTIImrkOfnaifb7cVZFf5/Z//BDiD+TUxnBAcLWmNROcd3zxQtpBF0E1OojwyuEIubg49aUr0tbZV2fIooCKPAhq0GP67yr4EzKcRnhi2lO9CdtvKT2GCytbi8lCWj2Z4bsqf5EgG22G9x09ePrOyk3SZvcnJQLA8yzziQCv+C2VRuQomH9/tfKxQCDEJ6IwZvBv4ADwp3ToTd/PviPi/DT/FLnzHU/ksFONTJ4axw7aM3tXdJ2Gm0B+pMFufG1OkYB6s+6RDFvNg+QtvIBWK93pW3L6qxEQIi5NP53JK8iZJ/DPidtmTEVNbryLTDsHLYqsK+Wb+Z7FBAvoK5h1iHNCCfGCcpydIel/SXxVsJC5t9cT+gRcpQwKmDWh5DDnLKXhow/K4w7xpBt07LKZ9qxX4NTzRCCBJ0SIrmr+QNYYnBLwgEZ4vUgd0QGOqNno6H9s8fpYWOlwAuAbVcibFEEaDfaS9BKCJC9fjajwXBpwMIkfgV8+dg7NsM4aFppjBWP+fYErX0PycQV+jXZOPPwHBzj8qETwoFrMmtrApsRfseY
Content-Type: multipart/related; boundary="_004_CY8PR14MB5954E72CBB4DB29B34612866D7DD9CY8PR14MB5954namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY8PR14MB5954.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cf2f43c-2389-4064-cf56-08db0de149a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2023 16:42:25.7347 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GlcnfZbqh353gV2mOOxQADPuM0wg9yrAXgNwgjocjQw11hJ3/FZla2qWB5wAHF+KitK08ChtZN5XKCDgqAyCfw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR14MB3771
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: bb40c47e-0dde-4de9-9142-46fa876b9208
X-VPM-MSG-ID: e0e53e45-f59d-41e7-9ea1-8bf89391ac77
X-VPM-ENC-REGIME: TLS,Plaintext
X-VPM-IS-HYBRID: 0
X-VPM: TLS Sent
X-VPM-TLS-SENDER: vmvpm01.z120.zixworks.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tdX0Clx0wrmJe4gembuT9TwFwjk>
Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 13 Feb 2023 16:42:34 -0000
Thanks Dave! Please let me know if you need any details from me. Mike From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Giuseppe Fioccola Sent: Monday, February 13, 2023 10:22 AM To: Gyan Mishra <hayabusagsm@gmail.com>; Joel Halpern <jmh@joelhalpern.com> Cc: 6man <ipv6@ietf.org>; SPRING WG List <spring@ietf.org> Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method [External email] Hi Gyan, Thank you for your support! Please find my replies inline tagged as [GF]. Regards, Giuseppe From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Gyan Mishra Sent: Saturday, February 11, 2023 9:06 AM To: Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> Cc: 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method I support WG adoption. The draft is clearly and succinctly written. This draft will be very useful for SRv6 performance measurements for on path IOAM telemetry. Few questions. Is the use and operation of the FlowMonID identical to how it’s described in RFC 9343 and if so then it’s identical to the RFC 6437 20 bit IPv6 header Flow label which is based on the standard 5-tuple header keys used in RFC 6437 for stateless load balancing on stateful signaling. At the bottom of Section 1 page 5 describes the Data Field format. At the bottom it talks about how to guarantee uniqueness of the flow for disambiguating the flow and that is the purpose of the 5-tuple header key to identify and disambiguate the flow so it’s uniquely identified as done with RFC 6437 stateless load balancing. [GF]: Yes, the FlowMonID is identical to how it is described in RFC 9343 but it is different from the Flow label, as also specified in RFC9343. We will clarify this point in this document as well. Use or SRH Alt Mark TLV - top of page 6 .. looks like a typo in the last sentence [GF]: Yes, we will fix it Old text Because SRv6 Is a routing header, destination options before the routing header are processed by each destination in the routing list. New text Because the SRv6 SRH is a routing header, destination options are processed by per RFC 8200 Section 4.1 Note 1 first destination that appears in the IPv6 destination address field plus subsequent destinations listed in the routing header. [GF]: Good suggestion. We can replace it. As mentioned by others this drafts leverages use of SRH used by SRV6, new SRH TLV used to encode the Alt Mark data fields to monitor every node along the SRH path. This is much more cost effective and optimal then adding additional EH DOH or HBH to encode the Alt Mark which is significant overhead and use of SRH TLV is most optimal for the Alt Mark PM encoding. [GF]: Agree. For SRv6 compression CSID draft as SRH is not used for Next SID flavor as long as hops is less than 5 hops, which in many cases for loose hops that is the case, maybe the Alt Mark meta data can be stored in a 16 bit service SID LIB - Local SID ID block for the PM on path telemetry. https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ [GF]: Good point. We can mention this case in the document. I think an Operational Considerations section would be a good idea as mentioned by others. Thanks Gyan On Wed, Feb 1, 2023 at 7:44 PM Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> wrote: This call is for the draft at: https://datatracker.ietf.org/doc/draft-fz-spring-srv6-alt-mark This email starts the WG adoption call for the subject draft (as requested by the authors, with apologies from the WG chairs for how long it has taken to kick this out.) This call will run through the end of the day on Feb 16. Pleaes read the whole email as there are a few points, and it is not that long. Please comment on whether you think this topic is something you think the spring WG should work, whether you think this draft is a good starting point for such work, any issues or concerns you have, and whether you would be willing to help be contributing and / or reviewing the work if the WG does choose to work on it. 6man is copied for their information, as this is different from but related to an extension header proposal in front of 6man. Authors and named contributors, please confirm to the list that all known, relevant, IPR has been disclosed. If it has note, please remedy this gap. The spring chairs have noted one aspect of this draft that caught our eye, and we would appreciate WG members who comment on the adoption to consider, and if possible opine, on this. As we read this draft, as distinct from the related 6man extension header work, this causes the recorded altmarks to only be updated at routers identified in the SRH segment list. (We presume this would include all identified points in a compressed container.) We could not tell from the document what the value was for this as distinct from getting the measurements at all routers. Do WG members understand and agree that it does have value? As a lesser point, we consider that one quote in the draft is misleading and will likely need to be reworded in the near future. The draft say "SRH TLV can also be used to encode the AltMark Data Fields for SRv6 and to monitor every node along the SR path." It is unclear if these was intended to mean all routers (most of which would not see this TLV) or if it was intended to refer to only those routers identified in the SRH, in which case we presume it will be reworded. Thank you, Joel -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com> M 301 502-1347 The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. This message was secured by Zix(R).
- [IPv6] WG Adoption call for Segment Routing Heade… Joel Halpern
- Re: [IPv6] WG Adoption call for Segment Routing H… Haoyu Song
- Re: [IPv6] WG Adoption call for Segment Routing H… Cheng Li
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Tianran Zhou
- Re: [IPv6] WG Adoption call for Segment Routing H… Greg Mirsky
- Re: [IPv6] WG Adoption call for Segment Routing H… Mauro Cociglio
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Greg Mirsky
- Re: [IPv6] WG Adoption call for Segment Routing H… Chongfeng Xie
- Re: [IPv6] [spring] WG Adoption call for Segment … xiao.min2
- Re: [IPv6] WG Adoption call for Segment Routing H… Dongjie (Jimmy)
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola
- Re: [IPv6] [spring] WG Adoption call for Segment … Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Greg Mirsky
- Re: [IPv6] [spring] WG Adoption call for Segment … Haoyu Song
- Re: [IPv6] WG Adoption call for Segment Routing H… Gyan Mishra
- Re: [IPv6] WG Adoption call for Segment Routing H… 庞冉(联通集团中国联通研究院-本 部)
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Ackermann, Michael
- Re: [IPv6] [spring] WG Adoption call for Segment … xiao.min2
- Re: [IPv6] WG Adoption call for Segment Routing H… Huaimo Chen
- Re: [IPv6] [spring] WG Adoption call for Segment … Xuewei Wang
- Re: [IPv6] [spring] WG Adoption call for Segment … Aijun Wang
- Re: [IPv6] [spring] WG Adoption call for Segment … Giuseppe Fioccola
- Re: [IPv6] [spring] WG Adoption call for Segment … Greg Mirsky
- Re: [IPv6] WG Adoption call for Segment Routing H… Nilo Massimo
- Re: [IPv6] [spring] WG Adoption call for Segment … Tianran Zhou
- Re: [IPv6] WG Adoption call for Segment Routing H… Ketan Talaulikar
- Re: [IPv6] [spring] WG Adoption call for Segment … Giuseppe Fioccola
- Re: [IPv6] [spring] WG Adoption call for Segment … Ketan Talaulikar
- Re: [IPv6] [spring] WG Adoption call for Segment … Robert Raszuk
- Re: [IPv6] [spring] WG Adoption call for Segment … Giuseppe Fioccola
- Re: [IPv6] [spring] WG Adoption call for Segment … Greg Mirsky
- Re: [IPv6] [spring] WG Adoption call for Segment … Robert Raszuk
- Re: [IPv6] [spring] WG Adoption call for Segment … Greg Mirsky
- Re: [IPv6] [spring] WG Adoption call for Segment … Greg Mirsky
- Re: [IPv6] [spring] WG Adoption call for Segment … Tianran Zhou
- Re: [IPv6] [spring] WG Adoption call for Segment … Ketan Talaulikar
- Re: [IPv6] WG Adoption call for Segment Routing H… Dhruv Dhody
- Re: [IPv6] [spring] WG Adoption call for Segment … Giuseppe Fioccola
- Re: [IPv6] WG Adoption call for Segment Routing H… Pengshuping (Peng Shuping)
- Re: [IPv6] [spring] WG Adoption call for Segment … Joel Halpern
- Re: [IPv6] WG Adoption call for Segment Routing H… bruno.decraene
- Re: [IPv6] WG Adoption call for Segment Routing H… Giuseppe Fioccola