Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Ron Bonica <rbonica@juniper.net> Tue, 21 January 2020 15:18 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF08C120090 for <spring@ietfa.amsl.com>; Tue, 21 Jan 2020 07:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Nf1woKcx; dkim=pass (1024-bit key) header.d=juniper.net header.b=Tcb7lXZl
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 mUWwQthGBFvc for <spring@ietfa.amsl.com>; Tue, 21 Jan 2020 07:18:50 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7EB12120178 for <spring@ietf.org>; Tue, 21 Jan 2020 07:18:50 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00LFHqfQ025843; Tue, 21 Jan 2020 07:18:48 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=wdANQgptG6LM2qnObJDnuTKeKoMQnONwSIXKK4vz7go=; b=Nf1woKcxIDTK82qtk75p3Ievbxd7YdA/hXGVprVBP22d31MDjEa5l6fDb4e3RUE376G8 D/tWaawhh8wDJAWbLo288SZxdfWsRUnvYuLJ6x8tixxqpirMmuaeOFd8LyCDDCfDatjO wGFVJt57u0BDa4FhR7oaYj6e4xg/88dV3iQyNnEZU9+tnNb3M5WpITDa5+SrJsKcglgn BRbZo4K43STRCpyiYYDPysFurd9i2iuTEV4z3AGBz2cH0dinQ0qQ50uXj79Me9C/E81U ueMeW8C52q6FRtPGYnOKJ3QPxZ0U9dhhti2gA7EQPvPr69RxzlTTNtvqsc2bkNa7d+wr cg==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by mx0b-00273201.pphosted.com with ESMTP id 2xnwuy0n48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 07:18:48 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SFVGFEvfsui7e1rbjtHuJWHhkOx5SVcPvwawQfHRZB6NgJr01nc0Bj66B6XdlFksg6o6wsJNmrvc/I1GqqICq2rIRySXI8YdXkisEngg9UqGV7xFwLBB6Ah+ahnVueJT/YsVXzNjhfUuRAjwCzPPF4fkS8mQRj9OMQDHK4uRFAcDXqCgt+7tDDHPgBC3LtOZYIxlnzswaOEZCF26gZCwEibuieXbxhLwxp5OtopBHWssLq5S0xORuMVwBQ27A9YIPZINOinSR05pi7bUTsdsiJgOWWqa0vAProWKnXLAqAUq5P4uLRtx8FPjEo8xMnqpIsv2FfjUT1LLV56+y0U/UA==
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-SenderADCheck; bh=wdANQgptG6LM2qnObJDnuTKeKoMQnONwSIXKK4vz7go=; b=EfK56XoJ+KFw6sf/vn/fNskwiW6R7HtNMTHpSeoBMUG8vZERweN8HccvZXIT52NDojxDPMsyT2YiRDo1pu2PNePCZXbeSLAvzLde+ftWujca8KIU8fLXsc8HTtfsC9SbcYgOLxl17beyA3C0i9yaWXLg+ECfJ5PmQh8s0x6gsfgMYp2XBcu5qWZ5Qb5VRGC8jlIIEKLKBNhsQf2zVrXB5UTeNx9DY+LN5kaVyZj//4wgL/A6LlgnMw1WeyWZnvRuJnY4MFqmPkqNPVxmLqwE1JZy+iYTev9LBPyWLu216FNJQkje9pflaqkUr4w1FF8EDFIF7dqBjOh8APG7H0IOnw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wdANQgptG6LM2qnObJDnuTKeKoMQnONwSIXKK4vz7go=; b=Tcb7lXZl2zExlJv5WdFO8p6f2OySMdXhRJjLNDKQTzJl2JiwymXc7AriSW4pdwqTGG8v/CskLj7sqHbVWWNCtplHRZmwskzwMzZMm0siOomJxxXhlaxp8b9Gp0hvnENQgCsVhXbQ+DjH8a3d8w/t1JKuRJsiewdISSWYXSVFYpI=
Received: from BN7PR05MB3938.namprd05.prod.outlook.com (52.132.216.30) by BN7PR05MB5889.namprd05.prod.outlook.com (20.176.30.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.15; Tue, 21 Jan 2020 15:18:46 +0000
Received: from BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864]) by BN7PR05MB3938.namprd05.prod.outlook.com ([fe80::f826:68df:3aa7:4864%5]) with mapi id 15.20.2665.015; Tue, 21 Jan 2020 15:18:46 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Greg Mirsky <gregimirsky@gmail.com>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AQHVyj6nD+ZMjcZoC0OhhD0ef5Rt9qfyaLsAgALd71A=
Date: Tue, 21 Jan 2020 15:18:45 +0000
Message-ID: <BN7PR05MB3938E73A8E2D389C5830354BAE0D0@BN7PR05MB3938.namprd05.prod.outlook.com>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CA+RyBmWQOgVmekANMLXVQeeBy9MK72Y653u0vpiW_GboqyDNUQ@mail.gmail.com> <238769EE-8272-420D-A2A4-BFECCE6E09AC@cisco.com> <CA+RyBmVkPK6Zv05vmmfHahXPJRRJ2SbWFuKTDTjBvvNFJWxqpw@mail.gmail.com> <70A6F938-29B0-473E-8559-7E20C7E992BD@cisco.com> <CA+RyBmVbYObSvcf9frfr8LBhKU5cmJ99o8mNJr_=CvH_z7j6Gw@mail.gmail.com>
In-Reply-To: <CA+RyBmVbYObSvcf9frfr8LBhKU5cmJ99o8mNJr_=CvH_z7j6Gw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-01-21T15:17:48.2485843Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a1db69a3-4b90-424a-8ff7-b24f1220df80; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [108.28.233.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5972898d-2fad-47b8-8fe6-08d79e85356b
x-ms-traffictypediagnostic: BN7PR05MB5889:
x-microsoft-antispam-prvs: <BN7PR05MB5889934454C535C08EA09889AE0D0@BN7PR05MB5889.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(189003)(199004)(71200400001)(55016002)(9686003)(33656002)(478600001)(966005)(2906002)(8936002)(81166006)(81156014)(66946007)(76116006)(66446008)(64756008)(66556008)(66476007)(86362001)(7696005)(8676002)(53546011)(52536014)(316002)(6506007)(5660300002)(110136005)(186003)(26005)(4326008)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB5889; H:BN7PR05MB3938.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eAqDZiOnJOhpnsVpV21aWmoJ88Etw9iawcRbefdEQbcW9eB38XizPHVDy+5JhrK0WzCWzTVvpcL5zM8bDkaJhQ1r71xE6T0QVx9MJmFE3+yH0aqEuUILCVAadZGougSb7bM7xbCgGgOZhHJjI2VlIvVZV2+kAyQTc7GMRLrfl0A8ODO+Wk3AZXTVj865NuKcZ+4uG07y4p88tvh+Kto/dsjPOI1mcIu06Znp8DKTHADpPOfJbrJ9/mdKkMZxnTE6AycATX4vTAQiIp5afTnaLXhIkRObSlOc8Je1FIK8DGKD6kqjlsBDd5AINRatf4n41qVM4RQ3EWEfxXcjtZl8paSo/YbN+FaABhGKZIZhMB3aomi7LdYc8fxrTCOVC+q0GITq37YW8q30rUcz75wIZbca7OXRew8NQTu7czu7k5wNJ9SSVVtGy1ObyLXcNWeeO2zGpfr9R40mI0HTQGqtwjN90djYmX41B5ExSaHMjpaCZ915hkmiMryq/3FyYIddQGZFpKFPbWq8GY1zjsdwNg==
x-ms-exchange-antispam-messagedata: ah3hKuJdIlhhC3eaqqUvo/nLLZUO1qYPwoEiMAvYreZvVKWEzySDCbby7zZ+tO/ZWbK3OcoN7oQpTq/1IB0k4hVyu0gzk+g6ph7SdlsvLbziwJqdDJlNnxhDvfEzgKVUwr2hRi62zhlLbS4tB86Ohg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN7PR05MB3938E73A8E2D389C5830354BAE0D0BN7PR05MB3938namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5972898d-2fad-47b8-8fe6-08d79e85356b
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 15:18:45.8386 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6n6BwFLy3ZyiVnmwNLJi27YHPixEOu3W6Gw9+osToKDFuALp/E2n69dreoQJKzdPSLNlrFlJhYPJBPM4OviQ6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB5889
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-21_04:2020-01-21, 2020-01-21 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 suspectscore=0 impostorscore=0 phishscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210123
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XZw3tLmO9BTK3VdfgN_8_j23pxc>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2020 15:18:56 -0000

Greg,

I also have reservations about putting the OAM-flag in the routing header for the following reasons:


  *   It has to be examined, even when Segments Left is equal to 0
  *   It is lost with PSP
  *   It has little to do with routing

                                                                            Ron


From: spring <spring-bounces@ietf.org>; On Behalf Of Greg Mirsky
Sent: Sunday, January 19, 2020 2:28 PM
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com>;
Cc: spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for sharing your opinion. I understand that you believe that draft-ietf-6man-spring-srv6-oam will not change and will be published with defining the O-flag as
      O-flag: OAM flag.  When set, it indicates that this packet is an
      operations and management (OAM) packet.
I, on the other hand, am much less certain that that draft and SRv6 OAM, in general, require the special flag in SRH. I believe that progressing the draft-ietf-spring-srv6-network-programming with the current text and the informative reference increases the likelihood that an Errata must be filed one the SRv6 OAM draft is published.
And as we're discussing a sub-section in the Operation section, I've got few questions on counters, hope you don't mind:

  *   As this is part of the operational considerations, should there be any recommendation on the length of the counters?
  *   Also, the usual drawback of detailed statistics to characterize a flow is scaling. Any consideration and recommendation on that?
  *   And last. I didn't find any of these counters being discussed in draft-ietf-6man-spring-srv6-oam. Perhaps you can help me with a reference to the SRv6 document that uses them..
Regards,
Greg


On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>> wrote:
Hi Greg,

Inline.

Thank you,
Pablo.

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Sunday, 12 January 2020 at 04:01
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming

Hi Pablo,
thank you for your expedient response. Please find my new notes under GIM>> tag below in-line.

Regards,
Greg

On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>> wrote:
Hi Greg,

Inline.

Thanks,
Pablo.

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Tuesday, 7 January 2020 at 21:01
To: Bruno Decraene <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, "6man@ietf.org<mailto:6man@ietf.org>" <6man@ietf.org<mailto:6man@ietf.org>>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent to: <cf@cisco.com<mailto:cf@cisco.com>>, <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>, <john@leddy.net<mailto:john@leddy.net>>, <daniel.voyer@bell.ca<mailto:daniel.voyer@bell.ca>>, <satoru.matsushima@g.softbank.co.jp<mailto:satoru.matsushima@g.softbank.co.jp>>, <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Resent date: Tuesday, 7 January 2020 at 21:01

Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document. Please kindly consider them as WG LC comments:
*         I have a question regarding the following pseudo-code:
  S08.   Max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in 8-octet units, not including the first 8 octets. Thus, as I understand, max_LE is the length in 8-octet units of half of the extension header less one. On the other hand, Last Entry and Segments Left are indices. Hence my question, What is being compared in line S09 ( Last Entry > max_LE)? Length and index? If the goal is to use Hdr Ext Len to calculate the number of entries in the header, then what assumption is used in S08? Is it that the entry's length is always and only 128 bits, i.e. 16 octets? I believe that using such an assumption is too narrowing and limiting to SRH.

PC: This has already been discussed with Adrian. Please check this thread: https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPrclGsIY$>
GIM>> Thank you for the reference. In some aspects, part of my statement is repeating your answer to Adrain. The only length on an element in SRH considered is 128 bits, the length of IPv6 address. I think that your explanation of how you have arrived at th following formula
    S08.   Max_LE = (Hdr Ext Len / 2) - 1
 will benefit the document.
My question to you and SPRING WG goes beyond this scenario. Considering presented in Singapore Unified Identifier proposals (draft-mirsky-6man-unified-id-sr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPmazF_FF$> and draft-wmsaxw-6man-usid-id-use<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/?include_text=1__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPlQOfPGd$>;), I believe other scenarios of using SRH, with elements of length other than 128 bits should be accommodated, e.g., 32 bits-long elements.
i.

PC: It is up to the draft-mirsky authors to standardize in their draft the changes to the SRH processing. As per today the draft-mirsky proposal is still an individual document.

*         Another question is to Section 6.3. What value do you see in this section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the Informational References section. I agree with that for the first sentence in the section. But I believe that the second sentence that refers to the new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam requires it to be moved into the Normative References section. Unless you'll decide to remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam are not required to understand or implement the technology described in draft-ietf-spring-srv6-network-programming. However, they are relevant as to provide additional information to the reader. Why would it be a normative reference?
GIM>> Ali and I are discussing several aspects of draft-ietf-6man-spring-srv6-oam. For example, the O-bit is applicable to any OAM operation or to some part of them. Note that OAM apparatus usually considered to include Fault Management and Performance Monitoring protocols. Both may operate as proactive or on-demand. Is the O-bit applicable to all OAM methods? Then, Fault Management OAM supports Continuity Check, Connectivity Verification and, for some networks, Automatic Protection Coordination. How O-bit is used in these methods? Now, to the Performance Monitoring OAM. I think that the O-bit can be only used in dual-ended one-way PM OAM. How O-bit may be used in single-ended two-way PM OAM? Can the O-bit support the Loss Measurement? As you may see, there are many questions to discuss and clarify in the document. I can imagine that the result of our work on draft-ietf-6man-spring-srv6-oam may be somewhat different from its current form. How to ensure synchronization between SRv6 programming and OAM specifications?

PC: The current reference in draft-ietf-spring-srv6-network-programming does not explain particular mechanisms of draft-ietf-6man-spring-srv6-oam. It only says that draft-ietf-6man-spring-srv6-oam defines OAM mechanisms for SRv6 as well as the O-bit. This is flexible enough as to be correct regardless of the changes that you make during the WGLC to draft-ietf-6man-spring-srv6-oam.

Regards,
Greg

On Thu, Dec 5, 2019 at 9:15 AM <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

Hello SPRING,



This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].



Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.



You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.



If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)



Thank you,

Bruno



[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPgy6NSUA$>




_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VMHP41W_vykFUzLLHFtba1B3jRPYZlG6mWgT4Md1iv5JpsOJ7DGNx3CwPp1Ddynn$>
--------------------------------------------------------------------


Juniper Business Use Only