Re: [OSPF] [spring] One question on E-flag of ABR/ASBR in OSPF SR extension

Chao Fu <chao.fu@ericsson.com> Fri, 19 May 2017 03:47 UTC

Return-Path: <chao.fu@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F68E12EC74 for <ospf@ietfa.amsl.com>; Thu, 18 May 2017 20:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 8BuzbE_BgscK for <ospf@ietfa.amsl.com>; Thu, 18 May 2017 20:47:27 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D56AD129BA8 for <ospf@ietf.org>; Thu, 18 May 2017 20:40:32 -0700 (PDT)
X-AuditID: c1b4fb25-35fff700000055fe-6d-591e692e7697
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.28.22014.E296E195; Fri, 19 May 2017 05:40:31 +0200 (CEST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 19 May 2017 05:40:29 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vpdMtkkxNstyuMyR3MzDPWbhX64AT40A3c2LASW/8kc=; b=XB+f7wh5pxoorGZ08MAXYekpIw2guYi5/7jFyHLD8uDHu0adZTfrrF8ZulqK0/hbWpJ97wsJzWu40X6HSoStmwzD45qCALZSbp0NBowkOMxImpbEnYT3cg3pi8WuMdeL6cZ4eCSvBMl/qoEJVZkctKQ/Or17JyzwHwGh4q8u590=
Received: from VI1PR07MB1071.eurprd07.prod.outlook.com (10.163.168.19) by VI1PR07MB1069.eurprd07.prod.outlook.com (10.163.168.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Fri, 19 May 2017 03:40:28 +0000
Received: from VI1PR07MB1071.eurprd07.prod.outlook.com ([10.163.168.19]) by VI1PR07MB1071.eurprd07.prod.outlook.com ([10.163.168.19]) with mapi id 15.01.1101.019; Fri, 19 May 2017 03:40:28 +0000
From: Chao Fu <chao.fu@ericsson.com>
To: Peter Psenak <ppsenak@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [spring] One question on E-flag of ABR/ASBR in OSPF SR extension
Thread-Index: AdLPqkMsp7Qw/GF8TGW2zt4btSR+jQACg/IAAABBuAAAAZlUAAAkfVyQ
Date: Fri, 19 May 2017 03:40:28 +0000
Message-ID: <VI1PR07MB1071C85B5B2FDFC188A2C57F91E50@VI1PR07MB1071.eurprd07.prod.outlook.com>
References: <VI1PR07MB1071503225586B964C69096191E40@VI1PR07MB1071.eurprd07.prod.outlook.com> <591D6136.2070208@cisco.com> <VI1PR07MB1071C58A7353F89F2A16F3A691E40@VI1PR07MB1071.eurprd07.prod.outlook.com> <591D6DAA.20407@cisco.com>
In-Reply-To: <591D6DAA.20407@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [106.38.5.68]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1069; 7:r4CebGmzrZ/iL3YgbdGaFbTVVkK+58ODAoNPkgyx2iPQYHeHzSAtLdS3uimDY8bf8c5FHQCRLkEVK/13N1vdHzSpUpnMIv7Hn7YFdaaROxoohJ/fP26xNS8RvAzQFmVbsdofJMuX7lbKQdoandqmanlJSiYnFjarJPOlrt+Tl9wqrX/Bkg0btpfXhtONZ0bWINi1/aIOJ4cxoOVBo2brZuaKB/JJTnTtsb4ZLJD4sohULCuFw3SsIPR0GkJ5/ZxTvSEbkw1pTNjjwrJRZ9lES9Aw5r+pFAwT3jI9hD5ZWR85m7/0maq54j17gY7v4DivTQ5Obv/LsxSEtmg3bTVLig==
x-ms-traffictypediagnostic: VI1PR07MB1069:
x-ms-office365-filtering-correlation-id: ed55d052-e476-4434-dd66-08d49e68cb07
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1069;
x-microsoft-antispam-prvs: <VI1PR07MB1069E0153401CEF0FE0C600791E50@VI1PR07MB1069.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(788757137089)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:VI1PR07MB1069; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1069;
x-forefront-prvs: 031257FE13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(24454002)(13464003)(5660300001)(8936002)(2501003)(122556002)(81166006)(7696004)(229853002)(2950100002)(25786009)(2900100001)(50986999)(54356999)(76176999)(53546009)(966005)(86362001)(478600001)(66066001)(189998001)(53936002)(93886004)(3280700002)(9686003)(6306002)(8676002)(3660700001)(7736002)(305945005)(6246003)(38730400002)(74316002)(33656002)(77096006)(5890100001)(102836003)(6116002)(3846002)(55016002)(99286003)(6436002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1069; H:VI1PR07MB1071.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 03:40:28.3768 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1069
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHefbu3V6txbN5O3gLRxI470pKRGVliGFlEqkYudrLFOeUvabZ l8zMUJP2wUxX4aWhLY1qmnnp4kR0U0oxLfIaKJYYJOKltCy3x6Bvv3P+/3MO53AYSlJIuzKp 6ixWo5arpAJ7fmX8ixC/gFTPhMBf5Ux4weSkMLy144bgIC+qbP0ZHaXX/+Sd5CXa71OwqtRs VhOwP9k+paTzHcpcc7/0pXkc5aER52JkxwAOhbU3i8JiZM9IcDeCqfsViARmBF091ymri49L KRiaOkuEch603zYJSNCDwPS5e7OEYQR4F9TUBFkLHHEktBqeCqzsgGOgdvEjTfLHocUyRhE+ CqNvB2kywBvMK/18K4twEqy0rVGk/zyC/HtXbSY7vBv0xhkbI+wMq32NPCtT2AVGZ6p4ZB8M +pcDFGEnmJveoK2NEC5FYDCsC4iwE/pGTULCHjBUVYII36RAq5dZlwHsAw/MoSQdA7Mrbbaz AL6F4HFR7daANChbfkITjofeuVmamBZ50NbfsGVyB7Nlcqu6iYaBD3eE5C6uMDFchLTIR/ff FoR9obpjUUBYBnU185TOdhoxWCpn+NWI/wg5cSx3Pl0ZHOLPalIvcFyG2l/NZhnR5neYmte9 W9H7bxFdCDNIul30PMkzQULLs7nc9C4EDCV1FLk4b6ZECnnuZVaTcU5zUcVyXciN4UtdRBGv B+MlWCnPYtNYNpPV/FN5jJ1rHvLDOq0irODrgheXk5juEXsozNE8bPIu+935XdEYdlfX47wg ib7Wnr+UvGdVZYyOO9YwEDij1ondCpWxnmOyDeUICq4TxzEyh4oi82zTXsO2nGmxtuSIPGHp 1J/eEwd861MsOx7WXwkTnvYd/1F+Run1admomZA4HX4VoIhskUn5XIo8yIfScPK/sbOZZRkD AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/KFlu-B5N5HkKWIGKNx4c7oCXU_w>
Subject: Re: [OSPF] [spring] One question on E-flag of ABR/ASBR in OSPF SR extension
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 May 2017 03:47:29 -0000

Hi Peter, 

Yes I think it is better to add the text that would say that ABR MUST NOT set the E-bit.
If not, when ABR receives the intra prefix with SID, it would be thought to inherit the SID value including its flags (NP and E) and then flood the SID to other areas. I guess that's why NP is described expressly on ABR not to do so. Then I think E-flag should be clarified also in case the non-directly attached prefix sets it. It could avoid any misunderstanding.
Anyway, the E-flag will not be set in this case, right? Thanks.

Regards,
Chao Fu

-----Original Message-----
From: Peter Psenak [mailto:ppsenak@cisco.com] 
Sent: Thursday, May 18, 2017 17:47
To: Chao Fu <chao.fu@ericsson.com>om>; spring@ietf.org
Subject: Re: [spring] One question on E-flag of ABR/ASBR in OSPF SR extension

Hi Chao,

On 18/05/17 11:15 , Chao Fu wrote:
> Hi Peter,
>
> It's right if the NP-flag is not set then the received E-flag is 
> ignored. But, if the NP-flag is SET because the prefix is not directly 
> attached to the ABR, E-flag will not be ignored

why would an E-bit be set in such case? It's up to the originator of the SID to decide when to set the E-bit. If the ABR does not set the E-bit no PHP would be done and advertised SID will be preserved.

Are you trying to add the text that would say that ABR MUST NOT set the E-bit either? I don't think it's necessary.

thanks,
Peter

> and the upstream neighbor will replace the Prefix-SID with the Explicit-NULL label 0. I guess actually the packet should be forwarded with the original prefix-SID, and no need to pop the 0 label and look up path again.
>
> Regards,
> Chao Fu
>
>
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Thursday, May 18, 2017 16:54
> To: Chao Fu <mailto:chao.fu@ericsson.com>; mailto:spring@ietf.org
> Subject: Re: [spring] One question on E-flag of ABR/ASBR in OSPF SR 
> extension
>
> Hi Chao,
>
> On 18/05/17 09:44 , Chao Fu wrote:
>> Hi,
>>
>> Should we clarify how to set E-flag for ABR/ASBR in OSPF SR extension?
>>
>> In
>> https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-14.
>> txt, the draft describes how to set NP-flag on ABR and ASBR (Section 
>> 5 [Page
>> 14]):
>>
>>      The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to
>> inter-
>>
>>      area prefixes that are originated by the ABR based on intra-area 
>> or
>>
>>      inter-area reachability between areas.  When the inter-area 
>> prefix is
>>
>>      generated based on a prefix which is directly attached to the 
>> ABR,
>>
>>      the NP-Flag SHOULD NOT be set.
>>
>>      The NP-Flag (No-PHP) MUST be be set for Prefix-SIDs allocated to
>>
>>      redistributed prefixes, unless the redistributed prefix is 
>> directly
>>
>>      attached to the ASBR, in which case the NP-flag SHOULD NOT be set.
>>
>> However, the E-flag (Explicit-Null Flag) is not described. Should we 
>> clarify it also? I think E-flag SHOULD NOT be set if the prefix is 
>> not directly attached to the ABR or ASBR, and if necessary, it SHOULD 
>> be set if the prefix is directly attached to the ABR or ASBR.
>
> The existing draft says:
>
> "If the NP-flag is not set then the received E-flag is ignored."
>
> Given that the draft clearly states when the NP-flag is set on ABR/ASBR above statement should be sufficient.
>
> thanks,
> Peter
>
>
>>
>> Regards,
>>
>> Chao Fu
>>
>>
>>
>> _______________________________________________
>> spring mailing list
>> mailto:spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
> .
>