I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other comments.

This document presents BGP constructs that may be used to implement certain
types of network segmentation.

   1. The Security Considerations section start off by stating:

   This document defines a new BGP SAFI for AFIs 1 and 2 and therefore
      does not change the underlying security issues inherent in the
      existing BGP protocol

   It isn't clear to this reader why the definition and introduction of a
   new element "therefore" doesn't change any underlying security
   characteristics. This should be explained better.
   2. The Security Considerations section also states:

   Mechanisms described in this document follow a "Walled Garden"
      approach

   Perhaps this is due to me not being an expert in this area and therefore
   missing it, but where in the document is it expressed that these mechanisms
   only apply to Walled Garden situations?
   3. It is stated that BGP origin validation "could" be used to "increase
   assurance" that information has not been falsified. Firstly, "could" does
   not say much to an implementer. Is this intended to be "SHOULD"? What's the
   risk of not using origin validation? And conversely, what assurance is
   given if BGP origin validation is not used (the "increased assurance" part).
   4. It is stated:

   In order to mitigate the risk of the diversion of traffic from its
      intended destination, existing BGPsec solution could be extended and
      supported for this SAFI

   Again,"could" is not part of RFC 2119, so not sure what is intended here.
   5. It is also stated that "as long as filtering [and other measures] are
   applied diligently, "risk of [traffic diversion] is eliminated" - is this
   really the case? That it is entirely eliminated?
   6. Not being an expert in this area, I just want to call out the
   following items that I ask the authors to ensure that they are covered:
      1. Is there anything in here which increases the risk of dDoS attacks?
      2. Do the mechanisms and constructs in this document introduce any
      new risks related to unintended information disclosure?
      3. Do the mechanisms and constructs in this document introduce any
      new risks due to spoofing of endpoint identities etc.?
      4. Do the mechanisms and constructs in this document introduce any
      new risks due to modification of information exchanged, e.g., between AS
      endpoints?

Editorial: Generally the document is in need of language clean-up, it uses
needless commas, etc. Three examples below just from the abstract:

   - The first sentence is very long and hard to follow. I suggest changing
   to:

   This document specifies a mechanism referred to as "Intent Driven
   Service Mapping." The mechanism uses BGP to express intent-based association
   of overlay routes with underlay routes that have specific Traffic
   Engineering (TE) characteristics satisfying a certain Service
   Level Agreement (SLA)."


   - .Likewise, I suggest changing the next sentence to (since a document
   in itself doesn't achieve anything):

   This is achieved by ...

   - I also suggest starting the second paragraph

   Additionally, this document specifies ...


Thanks,
--
-- Magnus