[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