BGP Control Plane for the Network Service Header in Service Function Chaining
draft-ietf-bess-nsh-bgp-control-plane-18

[Ballot comment]
As the IESG has rotated since this went up for a telechat, it's now shy of the needed ballot count to pass even when the DISCUSSes are cleared.  I'll ballot on this after I do a full review.

A quick comment now on -15:

Thanks for applying the feedback from my current and former co-ADs.  However, Adam Roach's review requested that "L3VPN", "NRLI", and "EVPN" be expanded on first use, but that still hasn't been done.

[Ballot discuss]
I think we may still need some text changes to clarify how the joint list
of SFIR-RD and SFIR Pool Identifier Extended Communities is constructed
and interpreted, and potentially need to register an RD Type matching
the other (TBD6+TBD7) values we allocate.

(I'm also not entirely clear how the IPv6 addresses interact with 8-byte RDs.)

A longer description of these topics is written up at
https://mailarchive.ietf.org/arch/msg/bess/wVDRF4ni0bGhNazvWoFi8BwJ_Vg/
but is not quite appropriate for this standalone context.

[Ballot comment]
[retaining the note that I support Roman's Discuss]
New comments on the -15

Section 2.2

  o  The Special Purpose SFT values range is assigned through Standards
      Action.  Values in that range are used for special SFC operations
      and do not apply to the types SF that may be placed on the SFC.

I'm not sure I understand what it means to "place a SF on the SFC".
Also, nit: missing "of"?

  o  The First Come First Served range tracks assignments of STF values
      made by any party that defines an SF type.  Reference through an
      Internet-Draft is desirable, but not required.

Maybe "Internet-Draft or other stable written specification?"

Section 8.10

The IPv6 examples seem to show RDs that are 127-bit IPv6 prefixes, but an
8-octet RD doesn't seem to have space for that?

Section 8.10.4

        SFP4:  RD = 2001:db8::198:51:100:1/104, SPI = 18,
                [SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1],
                [SI = 250, {SFT = 43, RD = 2001:db8::192:0:2:2/2,
                            SFT = 44, RD = 2001:db8::192:0:2:3/8 } ]
  [...]
  When the packets are returned to SFF1 by the SFI the SI will be
  decreased to 250 for the next hop.  SFF1 now has a free choice of
  next hop SFF to execute the next hop in the path selecting between
  all SFF2 that support an SF of type 43 and SFF3 that supports an SF
  of type 44.  These may be completely different functions that are to

I see a specific (nonzero) RD for SFT=43, so I don't understand why this is a
choice of "all SFF2 that support an SF of type 43".

Section 9

You say that RFC 4760 has additional relevant security measures but I'm not
sure which measures you're referring to (having skimmed all of 4760).

  This document does not fundamentally change the security behavior of
  BGP deployments which depend considerably on the network operator's

nit(?): maybe comma before "which"?

  perception of risk in their network.  It may be observed that the
  application of the mechanisms described in this document are scoped
  to a single domain as implied by [RFC8300] noted in Section 2.1.

I can't tell if this means section 2.1 of 8300 or this document.

[Ballot discuss]
(1) Controllers and other nodes.

Background: This document defines the new SFC NLRI, which has two distinct route types, originated by either a node hosting an SFI or a Controller.  Each route type has a specific function and it is reasonable to expect that the originators represent different nodes in the network, with different functions, location, etc..  BGP Capabilities Advertisement doesn't have a route type granularity; instead, a BGP speaker known to support the SFC NLRI could originate any type of route.

The facts above open the possibility that any node in the network can originate an SFPR and take over an SFP.  §3.2.2 does a very good job of explaining the potential existence of multiple Controllers and even offers the appropriate tie breaker to take control of the SFP: "MUST use the SFPR with the numerically lowest SFPR-RD". 

The document proposes no mitigation to the possibility of any node (a rogue node, for example) issuing SFPRs.  The assumption (§2.2) of "BGP connectivity between the Controllers and all SFFs" introduces also the ability to locate a rogue controller anywhere; I interpret "BGP connectivity" to include the presence of a router reflector (for example), which then allows distribution of SFPRs without going through a central policy point.

On one hand I think this condition is a feature (the Controller can be anywhere), but the case of a rogue node that wants to act as a controller is not considered.

To address this issue, I would like to see text that (1) acknowledges the issue (maybe in the security considerations section), and (2) discusses operational considerations for the placement, control, filtering, etc. of Controllers and the corresponding UPDATES from them and/or other nodes in the network.  IOW, the considerations around proper initial setup of the system should be clear.


(2) New Flow Specification Traffic Filtering Action

§7.4 (Flow Spec for SFC Classifiers) defines a new Traffic Filtering Action to be used with the Flow Specification NLRI.  rfc5775bis allows for any combination of Traffic Filtering Actions to be present, but this document says that "other action extended communities MUST NOT be present".  I believe that specifying the use of treat-as-withdraw is ok as a case of Traffic Filtering Action Interference -- I just say "ok" because it is not clear to me (nor explained anywhere) why other Traffic Filtering Actions cannot be used; for example, I could imagine rate-limiting the traffic into an SFP.

What concerns me more (and the reason for this DISCUSS point) is that rfc5575-only implementations will not consider the new Traffic Filtering Action, but could, depending on the components encoded in the NLRI, take actions based on other Traffic Filtering Actions.  The result can then be an inconsistent application of Traffic Filtering Actions in the network -- for example, some nodes may want to drop the matching traffic (traffic-rate of 0), while others may want to have the same traffic entering an SFP.

What are the operational considerations of using the new Traffic Filtering Action in a network where "legacy" (rfc5575bis-only) nodes exist?  Is there a potential migration path?  What might be the impact?  How can correct operation be verified?


(3) Use of the Control Plane

This last point is not specifically for the authors, but for the Responsible AD and the Chairs for the sfc WG (cc'd).

The SFPRs are built on, among other things, knowledge of the SFT(s) supported at a specific node.  I note that only one Special Purpose SFT is defined in this document.  The lack of SFT definitions means that no actual SFP can be instantiated.  IOW, without additional work to define new SFTs it seems to me that the control plane as specified in this document cannot be used. :-(

I couldn't find any related work (referencing this document) where new SFTs are proposed/defined.  What are the plans to develop that work?  Is there interest in the sfc WG to take advantage of the control plane?

[Ballot comment]
Non-blocking comments:

(1) I support Ben's DISCUSS point about the extension to the SFC Architecture.

(2) rfc7665/§5.2 (SFC Control Plane) lists the expected functionality provided by the control plane.  The last two points in the list are not part of the specification in this document, but there is no explanation why or if there is an alternate mechanism -- these are those points:

  5.  Provides the metadata and usage information classifiers need so
      that they in turn can provide this metadata for appropriate
      packets in the data plane.

  6.  When needed, provide information including policy information to
      other SFC elements to be able to properly interpret metadata.

(3) Add a Normative reference to rfc4360 (BGP Extended Communities Attribute).

(4) §3.1.1/§3.1.2: The two new Extended Communities are defined as different types.  Is it really necessary to request two different types, instead of one type with sub-types?  The transitive space is not close to exhaustion, but having a single type would make it easier for any future SFC-related extended communities to be identified/grouped.  Just a thought...

(5) Operational Considerations: there are multiple pieces of the puzzle that need to be coordinated, from RDs and RTs to pool identifiers and the assignment of SFIs to pools...  It would be very nice if all the information that needs to be operationally managed/provisioned was mentioned in a single place in the document...and if recommendations for the operator where included.

(6) §3.2.1 says that "Each TLV may include sub-TLVs", but that is not always true; for example, the length of the Association TLV is specified as being 12 (with no room for anything else).  This is a minor and easy issue to fix.

(7) §3.2.1: "Unknown TLVs SHOULD be ignored"  When would an unknown TLV not be ignored?  IOW, why not use MUST?

(8) §3.2.1.1 specifies a series of errors in the Association TLV that result in "SHOULD be ignored".  When would these values not be ignored, when would they be useful?  IOW, why not use MUST?

(9) Please review §7.4 against the language used in rfc5575bis for consistency.  For example "flow spec" is only used in the name of IANA registries or related entries; Flow Specification is used instead.

(10) Please include a pointer to I-D.ietf-idr-tunnel-encaps somewhere in §7.5.

(11) I would really like to see a registry set up for the bits in the new SPI/SI Representation sub-TLV.

(12) Other nits:

s/set to loopback address/set to the loopback address

s/[RFC4271] defines the BGP Path attribute./[RFC4271] defines BGP Path attributes.

[Ballot discuss]
Section 3.2.1.3 seems to talk about intermingling SFIR-RDs and SFIR Pool
Identifiers in a common list, but I do not see how it's defined to
intermingle the (six-octet) Pool Identifier Value with the (eight-octet)
RDs.

Section 3.1 seems to allow multiple SFIRs associated with a given RD,
but the rest of the document seems to assume that any RD has at most one
associated SFIR (as is stated explicitly for SFPRs).  (A few specific
mentions in the COMMENT.)

Within my own limited understanding, it seems like this document is
expanding the boundaries of the SFC Architecture in ways not envisioned
by RFC 7665 or 8300, and the shepherd writeup is pretty quiet on to what
extent this architectural change is accepted by the WG (as opposed to
being contained to just the BGP control plane mechanism).  I'd like to
get a positive affirmation from someone more familiar with the
discussions that this is moving the architecture in the right direction
with respect to things like:
- the introduction of the Service Function Type intermediate
  classification
- the more prominent treatment of looping, jumping, and branching as
  operations within a single SFP without reclassification by using the
  "Change Sequence" SFT entries to indicate these behaviors within the
  SFP definition itself (I note that RFC 7665 does not mention "jump" at all)
- the introduction of "gaps" in the SI sequence of a given SFP

With respect to SFT in particular, it sounds like this is intended to
help with scalability, which makes the genart reviewer's comment about
lack of implementation experience particularly poingant.  It seems like
SFIR pools perform a similar role, though of course not identical; I
didn't get a clear sense of why pools without SFTs are insufficient.

[Ballot comment]
I support Roman's Discuss.

Section 2.1

  In fact, each SI is mapped to one or more SFs that are implemented by
  one or more Service Function Instances (SFIs) that support those
  specified SFs.  Thus an SI may represent a choice of SFIs of one or
  more Service Function Types.  [...]

In my head a SI that maps to more than one SF implies a requirement to
do all of the listed SFs and in a specific order; "a choice of SFIs of
one or more types" seems to relax that a bit so that the order is
relaxed and perhaps the requirement to do all is also relaxed.  I think
"choice of SFIs for one or more" would alleviate that concern (if it is
even a real concern).

  in the underlay network.  How this indicator is generated and
  supplied, and how an SFF generates a new entropy indicator when it
  forwards a packet to the next SFF are out of scope of this document.

nit: comma after "next SFF".

Section 2.2

  This approach assumes that there is an underlay network that provides
  connectivity between SFFs and Controllers, and that the SFFs are
  grouped to form one or more service function overlay networks through
  which SFPs are built.  We assume BGP connectivity between the
  Controllers and all SFFs within each service function overlay
  network.

Are we thus implicitly not assuming BGP connectivity between arbitrary
pairs of SFFs?

Section 3

  The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST
  be set to loopback address of the advertising SFF.

nit: "a loopback address" (?)

Section 3.1

  Per [RFC4364] the RD field comprises a two byte Type field and a six
  byte Value field.  If two SFIRs are originated from different
  administrative domains, they MUST have different RDs.  In particular,
  SFIRs from different VPNs (for different service function overlay
  networks) MUST have different RDs, and those RDs MUST be different
  from any non-VPN SFIRs.

I think we should probably be a little more explicit that we reuse the
RD element (and the RD type/value semantics!) wholesale from RFC 4364
and
https://www.iana.org/assignments/route-distinguisher-types/route-distinguisher-types.xhtml
.  That is, we are not just reusing the layout, but the logical type as
well.

Also, are all of these "MUST"s indicating requirements that are new with
this specification, or are some of them inherited from RFC 4364?

The discussion later on in Section 4.2 suggests that perhaps these RDs
need to be unique per SFI, akin to how we say they are unique per SFP in
Section 3.2?

  The Service Function Type identifies the functions/features of
  service function can offer, e.g., classifier, firewall, load
  balancer, etc.  There may be several SFIs that can perform a given
  Service Function.  Each node hosting an SFI MUST originate an SFIR

This seems a bit of a non-sequitur: we go straight from SF*T*s to
discussion of the SFI/SF relationship, and we only mention "type" (but
not "SFT") in the rest of the paragraph, so the connection is harder to
return to than it need be.

  Note that a node may advertise all SFIs of one SFT in one shot using
  normal BGP Update packing.  That is, all of the SFIRs in an Update
  share a common Tunnel Encapsulation and RT attribute.  See also

I think we need to expand "route target".
Also, I suggest s/may advertise all/may advertise all its/

Section 3.1.2

I suggest explicitly stating that these MPLS labels are used to direct
incoming traffic to the SFI in question (fulfilling the promise made by
the abstract).

  Note that it is assumed that each SFF has one or more globally unique
  SFC Context Labels and that the context label space and the SPI
  address space are disjoint.

What I'm taking away from the last clause is roughly "we do not assume
that the values of SFC context labels have any structured relationship
to the corresponding SPI values", even though a strict reading of
"disjoint" would seem to be that "if a value is used in one setting it
is guaranteed to not be used in the other setting".  I think some
rewording may be in order.

Section 3.2

[our treatment of RD should presumably be consistent with Section 3.1,
if we make any changes there]

  byte Value field.  All SFPs MUST be associated with different RDs.
  The association of an SFP with an RD is determined by provisioning.

So this means that any given RD value can have at most one SFP
associated with it?  I guess that's needed in order to provide the level
of separation between SFPs that we need...

Section 3.2.1

Is there intended to be a distinction between the error-handling
behavior for error cases 1/2/6/7 and error case 4?  (If there is, I'm
not seeing it.)

      5., 8.:  The absence of an RD with which to correlate is nothing
        more than a soft error.  The receiver SHOULD store the
        information from the SFP attribute until a corresponding
        advertisement is received.

Should any sort of timeout also be applied?

Section 3.2.1.1

      SFP.  An SFP attribute SHOULD NOT contain more than one
      Association TLV with Association Type 1: if more than one is
      present, the first one MUST be processed and subsequent instances
      MUST be ignored.  Note that documents that define new Association

Do we want to say anything about checking consistency that (per these
rules) the forward SFP is associated with the backward, and the backward
SFP is associated with the forward one?  [I guess Section 7.1 is
probably enough.]

Section 3.2.1.3

[It's not clear to me that grouping by type gives any efficiency savings
here, as grouping by pool is available, and the semantics seem to be
equivalent to if the list of allowed SFI (pool)s was explicitly given
without the container.  A single pool containing all the SFIs in the
type would replace the SFIR-RD-value-zero semantics.]

Section 3.2.1.5

  The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
  length sub-TLV that can be carried in the SFP Attribute and indicates

If it's carried directly in the SFP Attribute, doesn't that make it a
non-sub TLV?

Section 3.2.2

  In all cases, there is no way for the receiving SFF to know which
  SFPR to process, and the SFPRs could be received in any order.  At
  any point in time, when multiple SFPRs have the same SPI but
  different SFPR-RDs, the SFF MUST use the SFPR with the numerically
  lowest SFPR-RD.  The SFF SHOULD log this occurrence to assist with

(The "interpreted as an 8-octet integer in big-endian form" is
implicit?)

Section 4.1

  The main feature introduced by this document is the ability to create
  multiple service function overlay networks through the use of Route
  Targets (RTs) [RFC4364].

As mentioned above, this seems like the second (not first) usage of
"RT".

Section 4.5

  When an SFF gets an SFPR advertisement it will first determine
  whether to import the route by examining the RT.  If the SFPR is
  imported the SFF then determines whether it is on the SFP by looking
  for its own SFIR-RDs in the SFPR.  For each occurrence in the SFP,

Also for non-specific SFT mentions that would apply, right?

Section 5

  o  There may be an obvious branch needed in an SFP such as the
      processing after a firewall where admitted packets continue along
      the SFP, but suspect packets are diverted to a "penalty box".  In
      this case, the next hop in the SFP will be indicated with two
      different SFT values.

My (admittedly poor) understanding of the SFC Architecture was that this
was best done as a reclassification, and that the various SFI options
for a given SI were intended to be roughly equivalent.  Am I just
imagining that?

  2.  From the SFP attribute of that SFPR, it finds the Hop TLV with SI
      value set to SI-y.  If there is no such Hop TLV, then such
      packets cannot be forwarded.

This seems to exclude the "gaps" in SI space that this document is
trying to allow.  Or is the gap processing to have already happened by
the time the SFF is at the "needs to forward" stage?

      A.  An SFIR is relevant if it carries RT-z, the SFT in its NLRI
          matches the SFT value in one of the SFT TLVs, and the RD
          value in its NLRI matches an entry in the list of SFIR-RDs in
          that SFT TLV.

      B.  If an entry in the SFIR-RD list of an SFT TLV contains the
          value zero, then an SFIR is relevant if it carries RT-z and
          the SFT in its NLRI matches the SFT value in that SFT TLV.
          I.e., any SFIR in the service function overlay network
          defined by RT-z and with the correct SFT is relevant.

Do we need to talk about expansion of pools as well?

  Thus, at any point in time when an SFF selects its next hop, it
  chooses from the intersection of the set of next hop RDs contained in
  the SFPR and the RDs contained in its local set of SFIRs.  If the
  intersection is null, the SFPR is unusable.  Similarly, when this
  condition obtains the originator of the SFPR SHOULD either withdraw
  the SFPR or re-advertise it with a new set of RDs for the affected
  hop.

(This seems to require a definition of "contained in" that includes
various types of expansion having been performed.)
nit: s/obtains/is detected/ (??)

Section 7.4

  o  If an SFC Classifiers Extended Community is received with SFT = 0
      then there are two sub-cases:

      *  If there is a choice of SFT in the hop indicated by the value
        of the SI (including SI = 0) then SFT = 0 means there is a free
        choice according to local policy of which SFT to use).

      *  If there is no choice of SFT in the hop indicated by the value
        of SI, then SFT = 0 means that the value of the SFT at that hop
        as indicated in the SFPR for the indicated SPI MUST be used.

side note(?): I think it would be possible to include the second case as
a special case of the first, as a "free choice" among all one allowed
values by the SFP for that SI.

  which the traffic belongs.  Additionally, note that to put the
  indicated SPI into context when multiple SFC overlays are present in
  one network, each FlowSpec update MUST be tagged with the route
  target of the overlay or VPN network for which it is intended.

I'd suggest making this requirement more prominent by putting it earlier
in the section.

Section 7.5

The description of these flags as describing "how the originating SFF
expects to see the SPI/SI represented" has some connotation of
exclusivity ("I expect to see an NSH" implying "I don't expect to see
anything else, including MPLS"), which does not seem like a good fit for
a bitmask where multiple bits can be set (as opposed to just a codepoint
for the encoding to use).

  The following bits are defined by this document:

  Bit 0:  If this bit is set the NSH is to be used to carry the SPI/SI
      in the data plane.

How are we numbering the bits?

Section 7.6

  When a classifier constructs an MPLS label stack for an SFP it starts
  with that SFP' last hop.  If the last hop requires an {SPI, SI} label

nit: "SFP's"

Section 8.1

  SFF1 followed by an SF of type 43 located at SFF2.  This path is
  fully explicit and each SFF is offered no choice in forwarding packet
  along the path.

nit: "forwarding packets" or "forwarding a packet"

Section 8.4

  This example provides a choice of SF type in the second hop in the
  path.  The SI of 250 indicates a choice between SF type 43 located
  through SF2 and SF type 44 located at SF3.

nit: s/located through/located at/?

  When the packets are returned to SFF1 by the SFI the SI will be
  decreased to 250 for the next hop.  SFF1 now has a free choice of
  next hop SFF to execute the next hop in the path selecting between
  all SFF2 that support an SF of type 43 and SFF3 that supports an SF
  of type 44.  These may be completely different functions that are to

nit: I think s/all SFF2 that support/SFF2 that supports/ ?

Section 8.8

Some pedantic part of me wants to complain that this is not a "branch",
since switching to SPF10 is the only option allowed at SI=250 on SPF11.

Section 8.9.1

It might make more sense to mvoe SPF13's definition before the paragraph
that talks about "sufficiently precisely specified SFPs", since SPF13
does not actually "specify [...] exact SFIs to use"

Section 9

I really like the way this section is written; thank you!

I think the core SFC documents cover enough of the considerations
inherent to looping, jumping, and branching that there's probably not
more to say here.

I'll list a handful of potential security topics I can think of after
reading the document, but that's not meant to imply that they all need
to be covered individually in the document: they are *potential* topics,
but may not end up being worth talking about.

We could perhaps note (again) the risk of misidentifying the overlay/VPN
on which a SFI receives a packet and its impact on the SPI/SI lookup,
but it's probably not strictly necessary.

With SFTs being allocated via FCFS, there is perhaps some risk that
different devices that actually provide qualitatively different
functionality will claim to provide the same SFT-number's service, which
potentially could cause problems.

There is perhaps room to talk about the specific bad things that can
happen if unsecured BGP is used (so that attackers can make false SFIR
announcements, false SFPR declarations, etc.), but it's not entirely
clear how useful that would be.

It might also be worth a specific mention of perimeter filtering so the
SFC configuration doesn't escape the local domain where it's intended to
be used.  (I would like to think this is sufficiently obvious, but am
not properly calibrated to make that call.)

Making "live" updates to an existing SFP is likely to have some level of
skew; if this involves both additions and removals it seems like there
is some risk of traversing "unsafe" configurations even when both old
and new configurations on their own would be safe.  (We do have
something of a recommendation to not do this earlier in the document
already, which is good.)

Is it too banal to say that adding more stuff to BGP messages make them
bigger and consume more resources to process?

  Chaining system.  The control plane mechanisms are very similar to
  those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the
  security considerations in that document (Section 23) provide good

s/23/13/

Section 10.4

[When I first saw "association TLV" I was expecting it to share a
registry with some other association grouping usages.  But I don't have
a particular complaint about doing it this way.]

[Ballot discuss]
* Section 9 cites a number of references (which cite additional references) on BGP security.  My summary of the highlights is:

(1) RFC4271 => TCP MD5 (RFC2385) is a MUST
(2) RFC4271 => consider RFC 3562 for key management guidance
(3) ietf-idr-tunnel-encaps => caution on Tunnel Encapsulation attribute
(4) rfc4364 => TCP MD5 is a non-rfc2119 “should”
(5) rfc4364 => don’t make connections with untrusted peers
(6) RFC7432 => references the utility of TCP-AO (RFC5925)

- Could the text articulate more clearly de-conflict (1), (4) and (6) – what is the recommended approach?

- a discuss-discuss – Given the green field nature of this specification (the shepherd’s report notes no implementation) and the assumed SFC deployment model (not the internet; a single provider’s operational domain where key management should be easier), could a more robust transport security option such as BGP over IPSec be RECOMMENDED?

[Ballot comment]
* Section 2.2.  Could you please clarify connect between these two statements about the SFC architecture:

1. “The SFIR is advertised by the node hosting the service function instance”

2. “We assume BGP connectivity between the Controller and all SFFs within each service function overlay network”

Is the node referenced in statement (1) the SFF.  If not, it seems like they need to be added to statement #2 as entities that have BGP connectivity.

* Section 2.2.  Per Figure 1, where is the “Controller” in this reference model?

* Section 3.1.  Per “If two SFIRs are originated from different administrative domains …”, are these administrative domains still in a “within a single provider's operational domain” per Section 2.2.?

* Section 3.1.1.  Per the SFIR Pool Identifier Value being “globally unique”, is that globally unique per Controller? Per overlay network?

* Section 4.3.  Per the summary notation of “RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }”, it isn’t clear to me what this expression is summarizing.  Also, what does the “*” mean?

* Section 4.5.1. Per “Therefore, while this document requires that the SI values in an SFP are monotonic decreasing, it makes no assumption that the SI values are sequential.”, should this “requires” be a RFC2119 MUST or REQUIRED?

* Section 6.  Per “Therefore, the use of NSH metadata may be required in order to prevent infinite loops”, what is this meta-data?

* Section 7.2.  Per “In such cases it can be important or necessary that all packets from a flow continue to traverse the same instance of a service function so that the state can be leveraged and does not need to be regenerated.”, how is this requirement signaled through the SFIRs for the computation of SFPs?

* Editorial Nits:
- Section 2.2. s/channelled/channeled/

- Section 4.5.1. s/bevahior/behavior/

- Section 7.1.  Per “As noted in Section 3.2.1.1 SFPRs reference each other one SFPR advertisement will be received before the other.”, this sentence didn’t parse for me.

- Section 8.9.1. Typo.  s/is is/is/

[Ballot comment]
— Section 1.2 —

  o  Service Function Overlay Network.  The logical network comprised
      of Classifiers, SFFs, and SFIs that are connected by paths or
      tunnels through underlay transport networks.

You use “comprises” correctly four other times in the document, but this one is incorrect: “comprised of” should instead be either “comprising” or “composed of”.  I only bother mentioning it because it’s right the four other times.

— Section 3.1 —

  The Service Function Type identifies the functions/features of
  service function can offer, e.g., classifier, firewall, load
  balancer, etc.

Should this be “a service function”, rather than “of service function”?  And a nit: you don’t need both “e.g.” and “etc.” together: either one will do on its own.

— Section 3.2.1 —

  o  The errors listed above are treated as follows:

      1., 2., 6., 7.:  The attribute MUST be treated as malformed and
        the "treat-as-withdraw" approach used as per [RFC7606].

      3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
        continue.

      4.:  Treated as a malformed message and the "treat-as-withdraw"
        approach used as per [RFC7606]

Why is 4 not included in the 1,2,6,7 group?  It seems odd to separate it and not to make it “MUST”, like the others.

— Section 9 —

  Service Function Chaining provides a significant attack opportunity:
  packets can be diverted from their normal paths through the network,
  can be made to execute unexpected functions, and the functions that
  are instantiated in software can be subverted.

The second item in the list appears to lack a subject:  can be made to execute unexpected functions.

[Ballot comment]

Thanks for the work on this document. I have only two comments, both
minor and editorial.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use, in the abstract, and in
the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for
guidance.

- NSH
- SFC
- AFI
- SAFI
- AF
- NLRI
- L3VPN
- EVPN

---------------------------------------------------------------------------

§8, §8.1, §8.2, §8.3, §8.4, §8.5, §8.6, §8.7, §8.7, §8.9.1, §8.9.2, §8.9.3,
§8.9.4, §8.9.1, §8.9.2:

All of the examples in these sections use IPv4 addresses exclusively. Please
update them to use IPv6 exclusively, or to use a mix of IPv4 and IPv6. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further details.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bess-nsh-bgp-control-plane-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are ten actions which we must complete.

First, in the Address Family Numbers registry located at:

https://www.iana.org/assignments/address-family-numbers/

a single, new registration will be made as follows:

Number: [ TBD-at-Registration ]
Description: BGP SFC
Reference: [ RFC-to-be ]
Registration Date: [ TBD-at-Registration ]

IANA will update the YANG module in the registry at https://www.iana.org/assignments/iana-routing-types as part of this registration.

Second, in the Subsequent Address Family Identifiers (SAFI) Parameters registry located at:

https://www.iana.org/assignments/safi-namespace/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: BGP SFC
Reference: [ RFC-to-be ]

As before, IANA will update the YANG module in the registry at https://www.iana.org/assignments/iana-routing-types as part of this registration.

Third, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Code: SFP attribute
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the SFP Attribute TLVs registry. The new registry is to be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

Values are in the range from 0 to 65535. The registration rules for the new registry are as follows [RFC8126]:

Values 0 and 65535 are to be marked "Reserved" and
Values 1 through 65524 are to be assigned according to the "First Come First Served" policy

IANA Question --> What is the registration policy [RFC8126] for values 65525 through 65534?

There are initial registrations in the new registry as follows:

Type | Name | Reference | Registration Date
------+-------------------------+---------------+------------------------
0 | Reserved
1 | Association TLV |[ RFC-to-be ] | [ TBD-at-Registration ]
2 | Hop TLV |[ RFC-to-be ] | [ TBD-at-Registration ]
3 | SFT TLV |[ RFC-to-be ] | [ TBD-at-Registration ]
4 | MPLS Swapping/Stacking |[ RFC-to-be ] | [ TBD-at-Registration ]
5-65524 Unassigned
65535 Reserved

Fifth, a new registry is to be created called the SFP Association Type registry.The new registry is to be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

Values are in the range from 0 to 65535. The registration rules for the new registry are as follows [RFC8126]:

Values 0 and 65535 are to be marked "Reserved" and
Values 1 through 65524 are to be assigned according to the "First Come First Served" policy

IANA Question --> What is the registration policy [RFC8126] for values 65525 through 65534?

There are initial registrations in the new registry as follows:

Type | Name | Reference | Registration Date
------+-------------------------+---------------+------------------------
0 | Reserved
1 | Bidirectional SFP |[ RFC-to-be ] | [ TBD-at-Registration ]
2-65524 Unassigned
65535 Reserved

Sixth, a new registry page entry on the IANA Protocol Registry Matrix located at:

https://www.iana.org/protocols

is to be created called Service Function Chaining Service Function Types. It's reference is to be [ RFC-to-be ].

Seventh, in the newly created Service Function Chaining Service Function Types registry page, a new registry is to be created called the Service Function Chaining Service Function Types registry.

Values are in the range from 0 to 65535. The registration rules for the new registry are as follows [RFC8126]:

Values 0 and 65535 are to be marked "Reserved"
Values 1 through 31 are to be assigned by Standards Action and are referred to as the Special Purpose SFT values
Values 32 through 65534 are to be assigned according to the "First Come First Served" policy

There are initial registrations in the new registry as follows:

Type | Name | Reference | Registration Date
------+-------------------------+---------------+------------------------
0 | Reserved
1 | Change Sequence |[ RFC-to-be ] | [ TBD-at-Registration ]
2-65524 Unassigned
65535 Reserved

Eighth, in the Generic Transitive Experimental Use Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

a single, new registration is to be made as follows:

Sub-type Value: [ TBD-at-Registration ]
Name: Flow Spec for SFC Classifiers
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

Ninth, in the BGP Transitive Extended Community Types registry also on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

two, new registrations are to be made as follows:

Type Value: [ TBD-at-Registration ]
Name: SFI Pool Identifier
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

Type Value: [ TBD-at-Registration ]
Name: MPLS Label Stack Mixed Swapping/Stacking Labels
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

Tenth, in the BGP Tunnel Encapsulation Attribute Sub-TLVs on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Name: SPI/SI Representation Sub-TLV
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-13):

From: The IESG
To: IETF-Announce
CC: stephane.litkowski@orange.com, draft-ietf-bess-nsh-bgp-control-plane@ietf.org, martin.vigoureux@nokia.com, bess-chairs@ietf.org, bess@ietf.org, Stephane Litkowski
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Control Plane for NSH SFC) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'BGP Control Plane for NSH SFC'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the use of BGP as a control plane for
  networks that support Service Function Chaining (SFC).  The document
  introduces a new BGP address family called the SFC AFI/SAFI with two
  route types.  One route type is originated by a node to advertise
  that it hosts a particular instance of a specified service function.
  This route type also provides "instructions" on how to send a packet
  to the hosting node in a way that indicates that the service function
  has to be applied to the packet.  The other route type is used by a
  Controller to advertise the paths of "chains" of service functions,
  and to give a unique designator to each such path so that they can be
  used in conjunction with the Network Service Header defined in RFC
  8300.

  This document adopts the SFC architecture described in RFC 7665.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3107/
  https://datatracker.ietf.org/ipr/2980/
  https://datatracker.ietf.org/ipr/3826/
  https://datatracker.ietf.org/ipr/2898/
  https://datatracker.ietf.org/ipr/3347/
  https://datatracker.ietf.org/ipr/3011/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7665: Service Function Chaining (SFC) Architecture (Informational - IETF stream)
    rfc8596: MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) (Informational - IETF stream)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document is requested to be a Proposed Standard. It defines some new BGP extensions that require interoperability.
This is the proper type of RFC and the type of RFC is clearly indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document defines a BGP controlplane for NSH based service chaining.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There is nothing particular to note. There is a good level of consensus on the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is no implementation or committed roadmap. However the WG supports the publication of the document as an RFC.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Stephane Litkowski is the document shepherd.
Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has done a deep review of the document and provided a list of comments to the authors.
The comments have been addressed.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are multiple IPR disclosed. There was no controversy about these IPRs.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There was no objection and a good support from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No, the document will require ietf-idr-rfc5575bis and ietf-idr-tunnel-encaps to be completed. However these documents are on a good track.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  ** Downref: Normative reference to an Informational RFC: RFC 7665
  ** Downref: Normative reference to an Informational RFC: RFC 8596

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is clearly written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are new IANA registries created , however none require Expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

n/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document is requested to be a Proposed Standard. It defines some new BGP extensions that require interoperability.
This is the proper type of RFC and the type of RFC is clearly indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document defines a BGP controlplane for NSH based service chaining.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There is nothing particular to note. There is a good level of consensus on the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is no implementation or committed roadmap. However the WG supports the publication of the document as an RFC.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Stephane Litkowski is the document shepherd.
Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has done a deep review of the document and provided a list of comments to the authors.
The comments have been addressed.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are multiple IPR disclosed. There was no controversy about these IPRs.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There was no objection and a good support from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No, the document will require ietf-idr-rfc5575bis and ietf-idr-tunnel-encaps to be completed. However these documents are on a good track.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is clearly written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are new IANA registries created , however none require Expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

n/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document is requested to be a Proposed Standard. It defines some new BGP extensions that require interoperability.
This is the proper type of RFC and the type of RFC is clearly indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document defines a BGP controlplane for NSH based service chaining.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There is nothing particular to note. There is a good level of consensus on the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is no implementation or committed roadmap. However the WG supports the publication of the document as an RFC.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Stephane Litkowski is the document shepherd.
Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has done a deep review of the document and provided a list of comments to the authors.
The comments have been addressed.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are multiple IPR disclosed. There was no controversy about these IPRs.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There was no objection and a good support from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No, the document will require ietf-idr-rfc5575bis and ietf-idr-tunnel-encaps to be completed. However these documents are on a good track.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is clearly written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are new IANA registries created , however none require Expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

n/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document is requested to be a Proposed Standard. It defines some new BGP extensions that require interoperability.
This is the proper type of RFC and the type of RFC is clearly indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document defines a BGP controlplane for NSH based service chaining.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There is nothing particular to note. There is a good level of consensus on the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is no implementation or committed roadmap.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Stephane Litkowski is the document shepherd.
Martin Vigoureux is the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has done a deep review of the document and provided a list of comments to the authors.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are multiple IPR disclosed. There was no controversy about these IPRs.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.


(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

n/a