Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt
Peter Psenak <ppsenak@cisco.com> Thu, 11 May 2017 09:16 UTC
Return-Path: <ppsenak@cisco.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 8689F12EB91; Thu, 11 May 2017 02:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level:
X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0muOt-4vu0d5; Thu, 11 May 2017 02:16:21 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697F312EB8F; Thu, 11 May 2017 02:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7324; q=dns/txt; s=iport; t=1494494180; x=1495703780; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZE2wOAuw5CMeiCf8z6evsZE/kS6cs/jxE12HLaw61bQ=; b=NmVxNJsEOtjlM2BL7ASfLAW0jJibCgORq4bb+a4Y+gmGnzbc3Plkv5vI mrDQbiqc/i6YVo+hlGxmQQVFv54xDNFSh6R6jZVOWZRiygqiXkFNgA7cG Ap2druBJBKArJ4AoiJynBw3MXjZj1NteiiVzAzXL+r8pxbbR1olmeRQ8K c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAAAUKxRZ/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBhDeBDI4Bc5BllXSCDyELhXgChUYYAQIBAQEBAQEBayiFFQEBAQECAQEBNjYKAQUHBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgEMAQUCAQGKFggOsw8SinQBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhl+BXQGDG4MhgSw8hUwBBJ4KhxyLf4IEVYRmg0OGaZRDHziBCi8gCBkVHCqEdhyBZT42iRkBAQE
X-IronPort-AV: E=Sophos;i="5.38,323,1491264000"; d="scan'208";a="654620344"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2017 09:16:18 +0000
Received: from [10.147.24.66] ([10.147.24.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4B9GHE4019078; Thu, 11 May 2017 09:16:17 GMT
Message-ID: <59142BE2.7090109@cisco.com>
Date: Thu, 11 May 2017 11:16:18 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Shraddha Hegde <shraddha@juniper.net>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
CC: "ospf@ietf.org" <ospf@ietf.org>
References: <149389189879.4821.567420168746411343@ietfa.amsl.com> <BN3PR05MB2706DD1C3249BDE683DF62E3D5EC0@BN3PR05MB2706.namprd05.prod.outlook.com> <5912BB0E.6070805@cisco.com> <BN3PR05MB2706B162184FA435C48F3931D5ED0@BN3PR05MB2706.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR05MB2706B162184FA435C48F3931D5ED0@BN3PR05MB2706.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/kF1ovWG25tvVJ7AoWQzfBq2eOAY>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt
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: Thu, 11 May 2017 09:16:24 -0000
Hi Shraddha please see inline: On 11/05/17 08:49 , Shraddha Hegde wrote: > Peter, > > It is clearly specified that ABR originating prefixes from other areas should have NP > Bit set. > > "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 same behavior should apply to mapping server advertised advertisements as well. when SRMS advertises the SID, it can not set the NP-Flag, so we can not apply the exact same behavior there. > > " As the Mapping Server does not specify the originator of a prefix >> advertisement, it is not possible to determine PHP behavior solely >> based on the Mapping Server advertisement. However, PHP behavior >> SHOULD be done in following cases: >> >> The Prefix is intra-area type and the downstream neighbor is the >> originator of the prefix. >> >> The Prefix is inter-area type and downstream neighbor is an ABR, >> which is advertising prefix reachability and is also generating >> the Extended Prefix TLV with the A-flag set for this prefix as >> described in section 2.1 of [RFC7684]." > > > While the text above captures the case of directly attached prefixes it does not cover the > Case of re-distributed prefixes for mapping server advertisements. there is a text in the draft right after the above mention text that talks about the redistribution case: "The Prefix is external type and downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]." > > Suggest to add below text. > > "The Prefix is inter-area type and downstream neighbor is an ABR, > which is advertising prefix reachability and is also generating > the Extended Prefix TLV with the A-flag re-set for this prefix as > described in section 2.1 of [RFC7684] then PHP MUST not be done" the draft says when PHP should be done when the SID is coming from the SRMS. It assumes that in all other cases PHP is not done. If we are going to say when the PHP must not be done for SID coming from SRMS, we need to list all cases, not only one of them. So I would say we either not say anything, or we say: "For all other cases, when SID is coming from SRMS, PHM MUST not be done" thanks, Peter > Rgds > Shraddha > > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, May 10, 2017 12:33 PM > To: Shraddha Hegde <shraddha@juniper.net>; internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: ospf@ietf.org > Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt > > Hi Shraddha, > > please see inline: > > On 10/05/17 07:34 , Shraddha Hegde wrote: >> Authors, >> >> Apologies for being late with this comment in the process of standardization. >> >> The below section 5 describes the PHP for mapping server >> >> >> " As the Mapping Server does not specify the originator of a prefix >> advertisement, it is not possible to determine PHP behavior solely >> based on the Mapping Server advertisement. However, PHP behavior >> SHOULD be done in following cases: >> >> The Prefix is intra-area type and the downstream neighbor is the >> originator of the prefix. >> >> The Prefix is inter-area type and downstream neighbor is an ABR, >> which is advertising prefix reachability and is also generating >> the Extended Prefix TLV with the A-flag set for this prefix as >> described in section 2.1 of [RFC7684]." >> >> >> The text says "PHP behavior" should be done in following cases. >> In the second case here it's an ABR re-advertising a prefix and SID >> being advertised for this Prefix from a mapping server. If we interpret "PHP behavior should be done" >> As the penultimate router removing the label and forwarding the packet >> to ABR, It does not work since the inner labels gets exposed at the ABR. > > above texts clearly specifies that PHP is done only for case where ABR is originating a prefix, not propagating it from other area. You can distinguish between the two based on the A-flag in the Extended Prefix TLV as specified in RFC7684, which the above text mentions. > > thanks, > Peter >> >> Request authors to add clarification text around "PHP behavior". >> >> Rgds >> Shraddha >> >> -----Original Message----- >> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Thursday, May 4, 2017 3:28 PM >> To: i-d-announce@ietf.org >> Cc: ospf@ietf.org >> Subject: [OSPF] I-D Action: >> draft-ietf-ospf-segment-routing-extensions-13.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Open Shortest Path First IGP of the IETF. >> >> Title : OSPF Extensions for Segment Routing >> Authors : Peter Psenak >> Stefano Previdi >> Clarence Filsfils >> Hannes Gredler >> Rob Shakir >> Wim Henderickx >> Jeff Tantsura >> Filename : draft-ietf-ospf-segment-routing-extensions-13.txt >> Pages : 35 >> Date : 2017-05-04 >> >> Abstract: >> Segment Routing (SR) allows a flexible definition of end-to-end paths >> within IGP topologies by encoding paths as sequences of topological >> sub-paths, called "segments". These segments are advertised by the >> link-state routing protocols (IS-IS and OSPF). >> >> This draft describes the OSPF extensions required for Segment >> Routing. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-exten >> sions/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions >> -13 >> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing- >> extensions-13 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-exte >> nsions-13 >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> . >> > > . >
- [OSPF] I-D Action: draft-ietf-ospf-segment-routin… internet-drafts
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Shraddha Hegde
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Ketan Talaulikar Talaulikar (ketant)
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Peter Psenak
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Shraddha Hegde
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Erik Auerswald
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Peter Psenak
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Shraddha Hegde
- Re: [OSPF] I-D Action: draft-ietf-ospf-segment-ro… Peter Psenak