Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Mirja,

Thanks for your review and your comments. 

Regarding your first comment, we have the following text in the Introduction section that describes the use-case/applicability that you are referring to in the Security Considerations.

   Segment Routing (SR) allows advertisement of single or multi-hop
   paths.  The flooding scope for the IGP extensions for Segment routing
   is IGP area-wide.  Consequently, the contents of a Link State
   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
   of an IGP area and therefore, by using the IGP alone it is not enough
   to construct segments across multiple IGP Area or AS boundaries.

   The flooding scope for the IGP extensions for Segment routing
   is IGP area-wide.  Consequently, the contents of a Link State
   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
   of an IGP area and therefore, by using the IGP alone it is not enough
   to construct segments across multiple IGP Area or AS boundaries.

   This document describes extensions to BGP-LS to advertise the SR
   information.  An external component (e.g., a controller) can collect
   SR information from across an SR domain (as described in [RFC8402])
   and construct the end-to-end path (with its associated SIDs) that
   need to be applied to an incoming packet to achieve the desired end-
   to-end forwarding.  The SR domain may be comprised of a single AS or
   multiple ASes.

Please let know any suggestions for the same or anything that needs further elaboration.

I will let Sue clarify on the shepherd's report. My impression was that many of the concerns raised were not specific to this particular BGP-LS extension but in general on BGP-LS itself. There has been a lot of discussions in the WG on this topic and work is ongoing to address some of those challenges based on our experience with BGP-LS deployments. One such effort is draft-ketant-idr-rfc7752bis. That said, all concerns raised specifically on this BGP-LS extension during the WGLC and follow-on reviews have been addressed AFAIK to achieve consensus.

Thanks,
Ketan

-----Original Message-----
From: Mirja Kühlewind via Datatracker <[e-mail]> 
Sent: 31 May 2019 15:18
To: The IESG <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-ext-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is the following statement on the applicability of this approach in the security consideration section:

“The SR traffic engineering
   policies using the SIDs advertised via BGP-LS are expected to be used
   entirely within this trusted SR domain (e.g. between multiple AS/
   domains within a single provider network).  Therefore, precaution is
   necessary to ensure that the SR information advertised via BGP-LS
   sessions is limited to consumers in a secure manner within this
   trusted SR domain.”

As this is every essential to the scope of the document I would like to see this earlier in the document, e.g. in the intro, and own applicability section, or even in the abstract.

One additional comment on the shepherd write-up:
I find the write-up a bit confusing but I assume that this document has wg consensus, even though it might be rough. There is a request to the IESG to make a judgment if this approach should be taken forward in general. However, if there are no technical or security concerns here and there is wg consensus, I don’t think I understand this request; expect this is not seen as covered by the charter, however, I don’t think this is indicated in the shepherd write-up.