Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017
"Susan Hares" <shares@ndzh.com> Wed, 08 March 2017 16:57 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4569F12946A; Wed, 8 Mar 2017 08:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 R44Byi2mg__8; Wed, 8 Mar 2017 08:57:19 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF38B1295CA; Wed, 8 Mar 2017 08:57:18 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29;
From: Susan Hares <shares@ndzh.com>
To: bruno.decraene@orange.com
References: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> <6339_1488991883_58C0368B_6339_12244_1_53C29892C857584299CBF5D05346208A1ED9982C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <6339_1488991883_58C0368B_6339_12244_1_53C29892C857584299CBF5D05346208A1ED9982C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Date: Wed, 08 Mar 2017 11:52:14 -0500
Message-ID: <01a301d2982c$571bd330$05537990$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A4_01D29802.6E48B160"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIZ1dTmxsGJmEzqH1hB3ufWIyDUXAI/EttyoOq0XGA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-TcEhK7XMYo48cZlRtmxC6kvzug>
Cc: idr@ietf.org, spring@ietf.org, 'Hannes Gredler' <hannes@rtbrick.com>
Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 16:57:21 -0000
Bruno: Thank you for cross-posing this to the spring WG. Sue From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, March 8, 2017 11:51 AM To: Susan Hares Cc: 'Hannes Gredler'; spring@ietf.org; idr@ietf.org Subject: RE: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 Cross-posting to SPRING WG as this document is highly related to draft-ietf-spring-segment-routing-msdc which is under WG Last Call in the SPRING WG. Ive read the document and have the following comments. ----- §2 A BGP-Prefix-SID is always global within the SR/BGP domain Do you imply that this extension may only be used within one SR/BGP domain? IOW all involved ASes must coordinate their BGP SID allocation? This would fit the MSDC use case discussed in draft-ietf-spring-segment-routing-msdc, but may be a restriction for other uses cases (e.g. Inter AS VPN option C requiring an inter-AS MPLS LSP). Could the document clarify/elaborate on this? One option may be for the ASBR to be configured to shit the received index by an offset (e.g. +1000). (this possibility could be referred to in section 6.1) -- §2 A BGP-Prefix-SID is always global within the SR/BGP domain On a side note, - on the BGP side, IMHO, a BGP domain probably means an AS (looking back up to RFC 1771 Im not seeing the definition of a BGP domain) - on the SR side, I think you mean that all ASes in the DC are in the same SR domain Hence SR domain does not equal a BGP domain. ----- §2: the newly proposed BGP Prefix-SID attribute can be attached to prefixes from AFI/SAFI: » §3: The BGP-Prefix-SID attached to a BGP prefix P §3.1: this TLV can be used to advertise the label index of a given prefix IINM, BGP Attributes are not attached to (IP) prefixes but shared by all prefixes of a given BGP UPDATE. In addition to the terminology point, this has consequences as: - [RFC3107] and [RFC4760] allow the advertisement of multiple IP prefixes per BGP UPDATE - draft-ietf-idr-bgp-prefix-sid would add the new requirement that each IP prefix be advertised in a dedicated BGP UPDATE. (unless multiple Label-Index TLB must be advertised) If this extension requires the use of one BGP update message per IP prefix, I think this point should be highlighted and discussed in both draft-ietf-idr-bgp-prefix-sid and draft-ietf-spring-segment-routing-msdc --- §2 the newly proposed BGP Prefix-SID attribute can be attached to prefixes from AFI/SAFI: Multiprotocol BGP labeled IPv4/IPv6 Unicast ([ <https://tools.ietf.org/html/rfc3107> RFC3107]). Multiprotocol BGP ([ <https://tools.ietf.org/html/rfc4760> RFC4760]) unlabeled IPv6 Unicast. If this attribute is found on routes of different AFI/SAFI, how is this handled? Is this considered an error (hence attribute is discarded as per §7) If so, this does not seem to work in Carriers carrier VPN case (where the CE use AFI/SAFI 1/4 routes, may attach the Prefix-SID attribute; then the PE will transform this route into a AFI/SAFI 1/128 with the same Prefix-SID attribute attached). If not, it must be clear that the BGP-Prefix-SID Index must not be used on the VPN route. Can this also be clarified in section 7 (error handling)? --- §4 The BGP Prefix SID attribute is an optional, transitive BGP path attribute. » Hence this attribute may spread very far, e.g. received over Internet routes. IPv6 Internet routes may be converted in AFI/SAFI 2/4 routes (labeled IPv6), in particular for AS running 6PE (RFC 4798). Hence this AS would interpret the Prefix SID and the received index would likely (or even deliberately) collision with Index provisioned by this AS. I think the use of a transitive attribute is debatable given that this attribute is not required for the service/network to work. i.e. its only nice to have in order for each node to use the same label (and assuming they can be configured with the same SRGB). So the document is trading security risk for a nice to have feature. --- §5.1 A BGP Prefix-SID attribute is called "unacceptable" for a speaker M if the derived label value L lies outside the SRGB configured on M. Otherwise the Label Index attribute is called "acceptable" to speaker M. » The case where two different IP Prefixes are received with the same Index (but with different labels) does not seem to be correctly handled. As per current text, both Prefix would incorrectly be merged into the same FEC (incoming label). Also, the index in the BGP Prefix-SID may collision with the same index, received from a different protocol (e.g. IS-IS) with a different prefix. How is this handled? This seems specifically an issue when combined with the previous point (comment). --- §5.2 (IPv6 SID) * S flag: if set then it means that the BGP speaker attaching the Prefix-SID Attribute to a prefix is capable of processing the IPv6 Segment Routing Header (SRH, [ <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04#ref-I-D.ietf-6 man-segment-routing-header> I-D.ietf-6man-segment-routing-header]) for the segment corresponding to the originated IPv6 prefix A similar text has just been removed in the latest version of the SR ISIS extension published yesterday (draft-ietf-isis-segment-routing-extensions-11). (cf H-Flag). Hence, are you sure that this SRv6 specific part is still applicable/up to date? --- 9. Security Considerations This document introduces no new security considerations above and beyond those already specified in [RFC4271] and [RFC3107]. Some of the comments above may probably have security considerations. --- Nits: §4.1 OLD: None are defined at this stage of the document. NEW: None are defined by this document. -- §2 OLD: the newly proposed BGP Prefix-SID attribute NEW: the BGP Prefix-SID attribute defined in this document -- 11. Change Log Initial Version: Sep 21 2014 This section does not seem that useful and could either be removed or completed with the change log of all versions. -- Name of the attribute is not consistently spelled (e.g. BGP-Prefix-SID, BGP Prefix SID, BGP Prefix-SID) Thanks Regards, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 4:27 AM To: idr@ietf.org Cc: 'Hannes Gredler' Subject: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 This message begins a 2 week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt (3/6 to 3/20). This draft proposed a new optional, transitive BGP path attribute, the BGP Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP Prefix SID) information for: Label-Index, IPv6 SID, and Originator SRGB. This draft is linked to work on DC segment routing describe draft-ietf-spring-segment-routing-msdc-03.txt. We have one remaining author (Arjun Sreekantiah) has not responded to the IPR call, but it is likely he will respond shortly. If Arun does not respond to the IPR call during the first week, this WG LC will be extended for 1 additional week. Three implementations exist and the details are on the web site, and in the draft: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implemen tations Sue Hares ____________________________________________________________________________ _____________________________________________ 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.
- [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-… Susan Hares
- Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-pre… bruno.decraene
- Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-pre… Susan Hares
- Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-pre… 'Hannes Gredler'