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

From: "Susan Hares" <[email-masked]>
Date: Sat, 16 Jun 2018 14:40:44 -0400

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:[email-masked]] 
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 <[email-masked]> 
Sent: 16 June 2018 04:59
To: Ketan Talaulikar (ketant) <[email-masked]>
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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 18 Jun 2018 03:56:39 +0000

Hi Sue,

Thanks for your report and I will work on your comments and inputs and get back.

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 17 June 2018 00:11
To: [email-masked]
Cc: [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; 'Alvaro Retana' <[email-masked]>; 'John Scudder' <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Shepherd's report for draft-ietf-idr-bgpls-segment-routing-epe-15 (with comments for draft-ietf-bgp-prefix-sid-25)

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."

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.

Sue Hares

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>>
Sent: 16 June 2018 04:59
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Subject: Do you have XML for draft-ietf-idr-bgpls-segment-routing-epe-15?

Ketan:

*        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