Re: [Idr] Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Mon, 15 October 2018 16:11 UTC

Return-Path: <ketant@cisco.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 B0958130EB8; Mon, 15 Oct 2018 09:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 bqUJDUqrNbBi; Mon, 15 Oct 2018 09:11:22 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14063130E9D; Mon, 15 Oct 2018 09:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33860; q=dns/txt; s=iport; t=1539619882; x=1540829482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JCutY9zNAQ91mcmu5OuW3Cn7LYe1NATtKOx2abOdwhY=; b=K2wB0hgJLTqaA57sPHDJJEDCyEcW4sjEzQEjLLSrsmMuDNhMngYZZNgw +1ja1AGQi2rHKiVMM6SEhVcTDBsNflBatHBmh5pVFiPbTFKn3M0AJbniJ B9pfZmYrBDhiwbXwEXaQjZ0aW3cZEcCbek55aOoIfX5ah/0MBgUUows82 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAARu8Rb/5hdJa1iGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQxIL2Z/KAqMAYwrgg16h3qOExSBZgsBASOESQKEXSE0DQ0BAwEBAgEBAm0cDIU5AQEBBCcGTBACAQgOAwQBASEBAgQHIREUCQgBAQQBDQUIgxgBgR1MAxUPp1wzhy4NghMFi0wXgUE/gRKCXTWBJoEwRQEBAQKBPgEBB02FJAKJEoUWVI18ZCAuCQKGU4ZjgxsfgU+EcIZ0gUaBJYdugSyDKXaITQIRFIEmHTiBVXAVO4JsgiYXEYhKhT0BbwGJKYEfgR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,385,1534809600"; d="scan'208,217";a="185599132"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Oct 2018 16:11:20 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9FGBKm7031607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Oct 2018 16:11:20 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Oct 2018 11:11:19 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Mon, 15 Oct 2018 11:11:19 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" <draft-ietf-idr-bgpls-segment-routing-epe@ietf.org>, 'Alvaro Retana' <aretana.ietf@gmail.com>, 'John Scudder' <jgs@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)
Thread-Index: AdQFoMYRO6E7cJxkRdioX6NPpOzBrBfAGzMQ
Date: Mon, 15 Oct 2018 16:11:19 +0000
Message-ID: <db2cb9392b044520b3e1e310f0b4c97d@XCH-ALN-008.cisco.com>
References: <010201d405a1$8965f120$9c31d360$@ndzh.com>
In-Reply-To: <010201d405a1$8965f120$9c31d360$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.42.234]
Content-Type: multipart/alternative; boundary="_000_db2cb9392b044520b3e1e310f0b4c97dXCHALN008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IG4yhVsO4reezq_NkCBq26khdF8>
Subject: Re: [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.29
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: Mon, 15 Oct 2018 16:11:26 -0000

Hi Sue,

Thanks a lot for your review and inputs/suggestions.


The updated version of the draft has just been posted to address your comments : https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-16

Overview of changes:

1)     Added text clarifying on iBGP usage

2)     Update text in security considerations

3)     Organized the sections a bit and added more text to clarify about which NLRI the TLVs are associated it (this is independent of BGP Prefix SID), and also which TLVs go in the NLRI descriptors and which ones go into BGP-LS Attribute.

4)     Update the manageability considerations to also cover fault handling and incorporated suggested changes on validity of fields.

5)     Editorial comments to clarify further on the following aspects:

a.      That the draft is about advertising of BGP Peering Segments (defined in SR Arch) via BGP-LS; not to be mixed with other types of SR segments.

b.      Added high level overview of what the BGP Peering Segments are and the primary Central EPE use-case which is the focus of the draft.

c.      Other clarifications on sub-TLV-->TLV, where they go in, semantics, etc.

Thanks,
Ketan

From: Susan Hares <shares@ndzh.com>
Sent: 17 June 2018 00:11
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>
Subject: Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)

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<mailto:shares@ndzh.com>>
Sent: 16 June 2018 04:59
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto: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