[Idr] Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)
"Susan Hares" <shares@ndzh.com> Sat, 16 June 2018 18:45 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 6256E130F11; Sat, 16 Jun 2018 11:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 fe_7n_BPmoGo; Sat, 16 Jun 2018 11:45:45 -0700 (PDT)
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 447CA124D68; Sat, 16 Jun 2018 11:45:34 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.103;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Cc: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org, "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, 'Alvaro Retana' <aretana.ietf@gmail.com>, 'John Scudder' <jgs@juniper.net>, "'Acee Lindem (acee)'" <acee@cisco.com>
Date: Sat, 16 Jun 2018 14:40:44 -0400
Message-ID: <010201d405a1$8965f120$9c31d360$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0103_01D40580.02567400"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdQFoMYRO6E7cJxkRdioX6NPpOzBrA==
Content-Language: en-us
X-Antivirus: AVG (VPS 180616-0, 06/16/2018), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_yH0OIjunEUI4DdYFDqN0hJrne4>
Subject: [Idr] Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.26
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: Sat, 16 Jun 2018 18:45:57 -0000
Stefano, Clarence, Keyur, Saikat, Jie, Ketan, Acee, and Mach: As the shepherd, I have major concerns, minor concerns, and editorial issues. To help move this process along, I've placed my additions to correct the minor concerns and editorial issues in a XML file, and given you a diff of the changes to -15. If anyone on the list cannot get the XML and PDF, I will post an individual draft with the corrections. I regret at this point not having a github center for IDR. Major concerns: 1) iBGP with route reflectors may cause looping problems. The BGP-EPE selects a "ships-in the night" approach and you are going against this approach. I've edited the document to highlight the two statements on iBGP. These segments either need to be deleted or the topic needs to be placed out of scope for the standard. 2) The security concerns section has to be reconsidered and rewritten before it is reasonable to send to the IESG. The RFC7752 was indicated as just information for a centralized controller on IGPs being passed in BGP so the data could be easily exported. This is clearly a ships-in-the-night case for the RFC7752. However this extension to RFC7752 specification gathers information by which you will reset the BGP configurations for BGP peer topologies and flows via BGP. Since the days of the ARPANET, a tight loop can cause security problems (unintentional or intentional). Please give this a considered discussion within the author team. Our Security ADs have a grasp of large systems, BGP, and the problems about using a protocol to modify a protocol. Tony Li and Robert Raszuk clearly stated in the draft-ietf-bgp-ls-segment-routing-ext WG LC that it was a mistake to allow RFC7752 in BGP, and that the SR additions "BGP is a great p2mp transport of routing information and information discussed is used primarily in p2p fashion. So allowing RFC 7752 to go forward just to reuse BGP transport and sessions to carry link state information only delays us to work and widely deploy much proper alternative transport(s) for those kind of information." See: https://www.ietf.org/mail-archive/web/idr/current/msg19124.html 3) You must specify what the BGP peer should do if it is a BGP-EPE peer and it receives both the BGP-LS bgp attribute and the BGP-prefix-sid attribute. Draft-ietf-idr-bgp-prefix-sid-25 indicates the network should either use SID additions for BGP-LS NLRI with the BGP attribute for BGP-LS for BGP-EPE. If this is true, then both specification (draft-ietf-bgp-prefix-sid-26 and draft-ietf-idr-bgpls-segment-routing-epe-16) need to add error handling language that indicates the reception of BGP-LS attributes with PEER-Node-SID, Peer-Adj-SID, or Peer-Set-SID in the BGP-LS attribute in a packet means that the BGP-prefix-SID attribute will be discard (attribute-discard error per RFC7606). Minor issues: The minor issues are the specification of the error handling in the document. In my understanding of your error handling, there are two types: format errors and content errors. Format errors can also be called malformed sub-TLVs in new Sub-TLV fields for BGP-LS Link NLRI (section 4.1) and malformed TLVs in the link attributes in the BGP attribute for BGP-LS. Content errors are fields which have the right form, but the wrong content. I've added text based on the hints in your documents. To provide easy access, these are also contained in the XML with a diff from version 15 in a pdf file. Please review these text additional carefully. Editorial issues: Since the editorial issues for the abstract, section 1, and portions of the document. I've decided to be efficient and simply provide a diff file and an XML update for version -15. Thank you for your patience with my slow response on this topic. Sue Hares From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, June 15, 2018 9:21 PM To: Susan Hares Subject: RE: Do you have XML for draft-ietf-idr-bgpls-segment-routing-epe-15? Hi Sue, Please find attached the XML for the drafts and thanks in advance for the shepherding. Thanks, Ketan From: Susan Hares <shares@ndzh.com> Sent: 16 June 2018 04:59 To: Ketan Talaulikar (ketant) <ketant@cisco.com> Subject: Do you have XML for draft-ietf-idr-bgpls-segment-routing-epe-15? Ketan: I'm finishing up my shepherd's report tonight on 2 of your drafts: . draft-ietf-idr-bgpls-segment-routing-epe-15.txt . draft-ietf-idr-bgp-ls-segment-routing-ext-08.txt If you have XML for these drafts, I will send you my shepherd updates in the XML with a diff. This way if you like the updates, you can choose to just accept them and republish. Cheerily, Susan Hares
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)
- [Idr] Shepherd's report for draft-ietf-idr-bgpls-… Susan Hares
- Re: [Idr] Shepherd's report for draft-ietf-idr-bg… Ketan Talaulikar (ketant)