Subject: [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

From: Bruno Decraene <[email-masked]>
Date: Wed, 13 Jun 2018 10:53:44 -0700

Reviewer: Bruno Decraene
Review result: Has Nits

 Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-idr-bgp-prefix-sid-21
Reviewer: Bruno Decraene
Review Date: 2018-06-13
IETF LC End Date:  2018-06-12
Intended Status: Standard Track

==========================
Summary:

    I have some minor concerns about this document that I think should be
    resolved before publication.

==========================
Comments:

Document is clear. Altough sometimes it's visible that the document has been
significantly edited over its history and could probably be made clearer with a
full rewrite from a single editor.

==========================
Major Issues:

§ IANA consideration

   "This document also requests creation of the "BGP Prefix-SID Label-
   Index TLV Flags" registry under the "Border Gateway Protocol (BGP)
   Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid.
   Initially, this 16 bit flags registry will be empty.  Flag bits will
   be allocated First Come First Served (FCFS) consistent with the BGP-
   SID TLV Types registry."

IMHO a registry of only 16 possible entries seems very small for a FCFS policy.
Anyone would be able to deplete it in minutes. (cf RFC 8126 "It is also
important to understand that First Come First Served really has no
filtering."). Is this really the intention of the WG? (Actually I'm wondering
what would be the monetary value of such a flag on the black market... If zero,
this means that the flag are useless. If non-zero, the benefit may be worth the
trouble)

Same comment for the "BGP Prefix-SID Originator SRGB TLV Flags" registry.

==========================
Minor Issues:

I think that the Abstract should mention that this specification is dedicated
to SR-MPLS (as opposed to covering both SR-MPLS & SRv6, which was the case at
the beginning of its history) ---------------------- §1

"A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment
   attached to a BGP prefix."

I'd propose the following change

   A BGP-Prefix Segment is a BGP labeled prefix with a Prefix-SID attached.

Rationals:
1) I'd rather say that this is the SID which is attached to the prefix, rather
than the Segment. 2) Given that this document is dedicated to SR-MPLS, we can
probably say that the BGP prefix is labeled.

But up to the authors.
-----
§1
"within the SR/BGP domain"
Can you point to the definition of "BGP domain"? If not, "SR domain" is
probably enough. ---
   The BGP Prefix-SID attribute defined in this document can be attached
   to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast
   ([RFC4760], [RFC8277]).  Address Family Identifier (AFI)/ Subsequent
   Address Family Identifier (SAFI) combinations.

1) The full point "." in the middle of the sentence is probably not intended.
2) I don't find the following text crystal clear: "BGP labeled IPv4/IPv6 Unicast
   ([RFC4760], [RFC8277]).  Address Family Identifier (AFI)/ Subsequent
   Address Family Identifier (SAFI) combinations."

IMO adding the numerical values would help (my undertanding is AFI/SAFI 1/4 and
2/4). Alternatively using the names as per the IANA registries. Also using the
AFI/SAFI order in "Address Family Identifier (AFI)/ Subsequent Address Family
Identifier (SAFI) " while the SAFI/AFI order in "BGP labeled IPv4/IPv6 Unicast"
is misleading.

Proposed NEW:
   The BGP Prefix-SID attribute defined in this document may be attached
   to BGP IPv4/IPv6 labelled routes. (AFI/SAFI 1/4 or 2/4).

-----
"o  A BGP Prefix-SID MAY be global between domains when the
      interconnected domains agree on the SID allocation scheme."

I think you mean :s/global/domain wide

(as opposed to the term "Global Segment" which has a different meaning.)

BTW in "A BGP Prefix-SID is always a global SID
([I-D.ietf-spring-segment-routing])" I guess you mean :s/global SID/global
segment

(for the same reason)

BTW2
"An SR domain
   is defined as a single administrative domain for global SID
   assignment."

Probably :s/global SID/domain wide SID

BTW3
"An SR domain
   is defined as a single administrative domain for global SID
   assignment."

may be :s/global SID assignment/domain wide SID assignement"
or :s/global SID/SID
-----
OLD
   o  A BGP Prefix-SID MAY be attached to a prefix.  In addition, each
      prefix will likely have a different AS_PATH attribute.  This
      implies that each prefix is advertised individually, reducing the
      ability to pack BGP advertisements (when sharing common
      attributes).

Proposed NEW:
   o  A BGP Prefix-SID MAY be attached to a prefix.  This
      implies that each prefix is advertised in individually, reducing the
      ability to pack BGP advertisements (when sharing common
      attributes).

(second sentence is not relevant to this specification and seems to be specific
to the MSDC use case)

---
"The BGP Prefix-SID advertised for BGP prefix P indicates that the
   segment routed path should be used"

 may be :s/segment routed path/SR segment

("segment routed path" is not well defined to me. Usually, the terms used are
"segment routing" or "soure routed path")) ---- "2.1.  MPLS BGP Prefix SID"
"4.1.  MPLS Dataplane: Labeled Unicast"

There is no need anymore for this title/hierarchy (given that SR-MPLS BGP
prefix SID are the only ones defined in this document (i.e. SRv6 removed) ----
"The operator assigns a globally unique label index,"

The SR architecture and SR-MPLS documents use either a "label" or a "index".
Here it's an index so I'd propose to use a consistent terminology, hence
:s/label index/index (Multiple times in the document.)

-----
      "The operator assigns a globally unique label index, L_I, to a
      locally sourced prefix of a BGP speaker N which is advertised to
      all other BGP speakers in the SR domain."

I thnk that BGP use the term "locally originated" (or simply "originated")
rather than "locally sourced prefix"

------
      "If the BGP speakers are not all configured with the same SRGB, and
      if traffic-engineering within the SR domain is required, each node
      may be required to advertise its local SRGB in addition to the
      topological information."

- What do you mean by "traffic engineering"? I think the issue comes from
stacking the BGP SID below other SID(s)/labels rather than related to
"traffic-engineering". - I think that "may be required to advertise its local
SRGB" is an understatement. (otherwise, please explain how the label is
computed) - "If the BGP speakers are not all configured with the same SRGB" how
is this information supposed to be known by the source node? Guessing seems
dangerous. - If we need the SRGB of the originator, we probably also need the
real SID of the originator. In which case, in the following sentence I think we
need :s/SHOULD/MUST

   "If multiple valid paths for the same prefix are received from
   multiple BGP speakers or, in the case of [RFC7911], from the same BGP
   speaker, and the BGP Prefix-SID attributes do not contain the same
   label index, then the label index from the best path BGP Prefix-SID
   attribute SHOULD be chosen ""

---

      "As defined in [I-D.ietf-spring-segment-routing], the label index
      L_I is an offset into the SRGB.  Each BGP speaker derives its
      local MPLS label, L, by adding L_I to the start value of its own
      SRGB, and programs L in its MPLS dataplane as its incoming/local
      label for the prefix."

Actually the way to compute the MPLS labels from the index and SRGB is defined
in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls Plus I'd
rather use a pointer to this SR-MPLS specification rather than re-specify the
computation. (especially since the text/algo is different, because the text
from draft-ietf-idr-bgp-prefix-sid simply assumes that the SRGB is composed of
a single block, which is not general enough for a specification. --- "
      Section 3.1 of this document specifies the Label-Index TLV of the
      BGP Prefix-SID attribute; this TLV can be used to advertise the
      label index for a given prefix.

   In order to advertise the label index of a given prefix P and,
   optionally, the SRGB, an extension to BGP is needed: the BGP Prefix-
   SID attribute.  This extension is described in subsequent sections."

Could probably be rephrased to avoid redundancy.
---
"   The Label-Index and Originator SRGB TLVs are used only when SR is
   applied to the MPLS dataplane."

Given that the scope of this document is now only MPLS-SR, this sentence may
probably be removed. ----- "SRGB: 3 octets of base followed by 3 octets of
range."

The term "base" is not defined neither in SR-architecture, SR-ISIS, SR-MPLS.

Actually SR-ISIS and SR-MPLS use different terms... and both documents are
under WGLC... SR-MPLS: "the SRGB is specified by the list of
   MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
   where  Ll(i) =< Lh(i)."

SR-ISIS:
One or more SRGB Descriptor entries, each of which have the
      following format:

         Range: 3 octets.
         SID/Label sub-TLV (as defined in Section 2.3).
-----

   "The Originator SRGB TLV contains the SRGB of the node originating the
   prefix to which the BGP Prefix-SID is attached.  The Originator SRGB
   TLV MUST NOT be changed during the propagation of the BGP update.

   The originator SRGB describes the SRGB of the node where the BGP
   Prefix SID is attached. "

   Some redundancy (1rst and last sentence) could be removed.
-----
"   The receiving routers concatenate the ranges and build the Segment
   Routing Global Block (SRGB) as follows:

         SRGB = [100, 199]
                [1000, 1099]
                [500, 599]

   The indexes span multiple ranges:

            index=0 means label 100
            ...
            index 99 means label 199
            index 100 means label 1000
            index 199 means label 1099
            ...
            index 200 means label 500
            ..."

I'm not sure that there is a need to respecify the way labels are computed from
SRGB and index. A reference to SR-MPLS would probably be better. ------ OLD:
   Consistent with [RFC7606], only the first occurrence of the BGP
   Prefix-SID attribute will be considered and subsequent occurrences
   will be discarded.  Similarly, only the first occurrence of a BGP
   Prefix-SID attribute TLV of a given TLV type will be considered
   unless the specification of that TLV type allows for multiple
   occurrences.

Proposed NEW (even more consistent with RFC 7606)
   As per with [RFC7606], if the BGP
   Prefix-SID attribute appears more than once in an UPDATE
       message, then all the occurrences of the attribute other than the
       first one SHALL be discarded and the UPDATE message will continue
       to be processed.
   Similarly, if a recognized TLV appears more than once in an BGP
   Prefix-SID attribute while the specification only allows for a single
   occurence
       , then all the occurrences of the TLV other than the
       first one SHALL be discarded and the Prefix-SID attribute will continue
       to be processed.

That being said, the first sentence does not define any new behavior, so is not
really needed IMHO. -----

"4.1.  MPLS Dataplane: Labeled Unicast

   A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6
   Unicast ([RFC8277]) AFI/SAFI is required.

   The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY
   contain the Originator SRGB TLV.  A BGP Prefix-SID attribute received
   without a Label-Index TLV MUST be considered as "invalid" by the
   receiving speaker."

Stricto census, the sentence prohibits the use of the BGP Prefix-SID  for other
usage than carrying Label-Index, including for non labeled AFI/SAFI. I think
you rather mean the following

proposed NEW:
When the  BGP Prefix-SID attribute is attached to a BGP labeled IPv4 or IPv6
   Unicast ([RFC8277]) AFI/SAFI, it MUST contain the Label-Index TLV and MAY
   contain the Originator SRGB TLV.  A BGP Prefix-SID attribute received
   without a Label-Index TLV MUST be considered as "invalid" by the
   receiving speaker.
----
OLD:
   The label index provides the receiving BGP speaker with guidance as
   to the incoming label that SHOULD be assigned by that BGP speaker.

The sentence could probably be simplified. e.g.

NEW   The label index provides guidance, to the receiving BGP speaker, for the
choice of its incoming label.

---
"   If multiple valid paths for the same prefix are received from
   multiple BGP speakers or, in the case of [RFC7911], from the same BGP
   speaker, and the BGP Prefix-SID attributes do not contain the same
   label index, then the label index from the best path BGP Prefix-SID
   attribute SHOULD be chosen with a notable exception being when
   [RFC5004] is being used to dampen route changes."

It's not clear to me why the situation is different with RFC5004, nor what
should be done in this case. Could you please elaborate? --- "It should be
noted that while SRGBs and
      SIDs are advertised using 32-bit values, the derived label is
      advertised in the 20 right-most bits."

The derived labeled is not advertised, so I don't understand the goal/meaning
of the sentence.

-----

§ Security considerations

   "To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
   (DDoS) attack due to excessive BGP updates with an invalid or
   conflicting BGP Prefix-SID attribute, message rate-limiting as well
   as suppression of duplicate messages SHOULD be deployed."

What do you mean exactly by "message rate-limiting"? Especially what do you
mean by "message" and what is "rate-limited" exactly? The local use of the
Prefix SID attribute? It's propagation? In which case, should be propagation
delayed or never propagated?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Jun 2018 01:02:29 +0000

Hi Bruno, 

Thanks for your review - you’ve raised some heretofore undetected ambiguities that need to be rectified. I've taken most of your comments. I plan to publish an update including all the comments that I've incorporated (tonight or tomorrow morning).

See replies inline. 

On 6/13/18, 1:53 PM, "Bruno Decraene" <[email-masked]> wrote:

    Reviewer: Bruno Decraene
    Review result: Has Nits
    
     Hello,

    

    

Yes - the original editors will be forever in my debt ;^) 

    § IANA consideration

    

I don't believe we need to consider attacks on the FCFS registries. You've got to believe that IANA will only consider legitimate requests. If not, it seems the whole concept of FCFS is flawed.

Since the BGP Prefix-SID attribute could be extended in the future to SRv6, I don't want to make such distinction. 

    

    Rationals:

I agree this is better but will leave out the "labeled" since the attribute could be extended in the future. 
    
    But up to the authors.

    -----
    §1

Agreed.

This is fixed in the -22 version. 

    Proposed NEW:

A previous review asked for expansion of AFI/SAFI. I will change the order to "BGP IPv4/IPv6 Labeled Unicast" consistent with AFI/SAFI throughout. 
    
    -----

Since I've defined SR domain more precisely, I will replace the unqualified "domain" with "AS" in this sentence. 

    Segment

No - I mean a global SID which is an index into the SRGB. 
    
    (for the same reason)
    
    BTW2
    "An SR domain

No - it is the scope of the global SID assignment. 
    
    BTW3
    "An SR domain

No

    -----
    OLD
    
    Proposed NEW:

Agreed. 
    
    ---

You don't think it is clear that the "segment routed path" uses SR segments for routing???

I'm going to retain the hierarchy since separating out the MPLS specific part will make it more straight forward to extend the document to SRv6 in the future. 

I don't want to change this since I believe it was Alvaro who asked for "label index" in a previous review. 
    
    -----

Agreed. 
    
    ------

What are you suggesting? This is just setting the context for the two alternatives for SRGB advertisement and indicating that BGP-LS is the preferred one for TE in the general sense. If this a rat-hole that will result in much debate, I could remove both these statement relating to traffic engineering as they are not required for the normative specifications in this document. 

    ---

Ok - I now reference draft-ietf-spring-segment-routing-mpls. 

    

I agree. Given the whole section described the BGP Prefix-SID attribute, this paragraph can be removed. 

    ---
    
    Given that the scope of this document is now only MPLS-SR, this sentence may
    probably be removed. ----- 

I'd leave it in to simplify extension to the SRv6 data plane with a subsequent document. 

"SRGB: 3 octets of base followed by 3 octets of
    range."

    
    SR-ISIS:
    
             Range: 3 octets.

I will use the following unambiguous definition:

           3 octets specifying the first label in the range followed
            by 3 octets specifying the number of labels in the range.

    -----
    
       "The Originator SRGB TLV contains the SRGB of the node originating the
       prefix to which the BGP Prefix-SID is attached.  The Originator SRGB
       TLV MUST NOT be changed during the propagation of the BGP update

I agree. The last sentence will be removed. 

    -----
    
             SRGB = [100, 199]
                    [1000, 1099]
                    [500, 599]

                index=0 means label 100
                ...
                index 99 means label 199
    
    I'm not sure that there is a need to respecify the way labels are computed from
    SRGB and index.        A reference to SR-MPLS would probably be better. 

Someone asked for an examples way back in the review process (way before I had taken over as editor). However, I will change this to a  reference to the SR-MPLS document.

------ OLD:

I think it is good to have application of RFC 7606 specified explicitly. I have updated as you proposed. 

    

    proposed NEW:

I agree this is better and consistent with my desire not to preclude extension to SRv6 or other address families. 

    ----
    OLD:

I'll go with a variation of that:

    The label index provides guidance to the receiving BGP speaker as to its 
    choice of incoming label.

    ---
    
    It's not clear to me why the situation is different with RFC5004, nor what
    should be done in this case. Could you please elaborate? --- 

RFC 5004 dampens the rate at which BGP changes the best-path. This was also one of Alvaro's comments. 

"It should be

I think this came from the IGP drafts. I will remove it. 
    
    -----

    

Although you are the first person to misinterpret this, I will replace "message" with "error log message" to avoid confusion with BGP protocol messages. 

Thanks,
Acee

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 14 Jun 2018 14:35:42 -0400

Hi,

See below

> On 6/13/18, 1:53 PM, "Bruno Decraene" <[email-masked]> wrote:

While I greatly respect IANA and the quality of service they provide,
the main idea of the transition of authority for protocol parameters
from John Postel ( aka "King John") to IANA was to make the IANA task
as objective and clerical as possible, deferring all required
judgements to experts or standards actions or whatever as specified in
the registry in question. The theory that "IANA will only consider
legitimate requests" implies, unless "legitimate request" is
specifically defined in this draft (which pretty much negates FCFS),
judgements that IANA is not contracted for and not supposed to be
making.

I have a lot of sympathy for the view that the concept of FCFS is
flawed and should almost always be Expert Review instead. But, there
are some cases of essentially infinite values available (e.g., a
multi-precision integer parameters or lengthy string values). And, in
any case, where a registry has tens of thousands of values that are
usually allocated one or a few at a time, there is one saving
paragraph in RFC 8126 as follows:

   IANA always has the discretion to ask the IESG for advice or
   intervention when they feel it is needed, such as in cases where
   policies or procedures are unclear to them, where they encounter
   issues or questions they are unable to resolve, or where registration
   requests or patterns of requests appear to be unusual or abusive.

But I think it is unwise to depend on this. Note that IANA has NO
authority to refuse a registration for FCFS, they could only delay
responding and refer it to the IESG if they happen to notice it as
being suspicious. And I don't know if there has ever been a case where
IANA has done this. As it says in RFC 8126:

   It is also important to understand that First Come First Served
   really has no filtering.  Essentially, any well-formed request is
   accepted.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Jun 2018 20:27:25 +0000

No Mas... Although the use cases for flags relating to these specific TLVs should be few and far between, I anticipate there will be continued FCFS registry attack trepidation. I'll change them to expert review. 
Thanks,
Acee 

On 6/14/18, 2:36 PM, "Donald Eastlake" <[email-masked]> wrote:

    Hi,
    
    See below

    

    
    
    Thanks,
    Donald

---

From: <[email-masked]>
Date: Fri, 15 Jun 2018 16:14:27 +0000

Hi Acee,

Thanks for your quick reply, accommodating my comments,  and the updated draft.

Please see comments inline [Bruno]

> From: Acee Lindem (acee) [mailto:[email-masked]]
 > Sent: Thursday, June 14, 2018 3:02 AM
> 
 > Hi Bruno,
 > 
 > Thanks for your review - you’ve raised some heretofore undetected ambiguities that need to be
 > rectified. I've taken most of your comments. I plan to publish an update including all the comments
 > that I've incorporated (tonight or tomorrow morning).
 > 
 > See replies inline.
 > 
 > I don't believe we need to consider attacks on the FCFS registries. You've got to believe that IANA
 > will only consider legitimate requests. If not, it seems the whole concept of FCFS is flawed.

[Bruno]
As you changed the registry to "Expert review", I believe additional guidance need to be indicated to the expert. (sorry, and I'm not even paid by the number of comments ;-) )
According to https://tools.ietf.org/html/rfc8126#section-4.5

   "The registry's  definition needs to make clear to registrants what information is
   necessary.  [...]

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.  It is also a good idea to include, when possible, a sense
   of whether many registrations are expected over time, or if the
   registry is expected to be updated infrequently or in exceptional
   circumstances only."

[Bruno] I agree for the first part.
Regarding the last part, such distinction is already explicit in the draft: "The applicability and support for Segment Routing over IPv6 is beyond the scope of this document."

I'm asking to make this clear from the abstract.
IOW, the content of the document has changed by removing all SRv6 content. It seems logical to me that the Abstract be also updated to reflect that change. e.g.

OLD:
   This document defines an optional, transitive BGP attribute for
   announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
   information.

NEW
   This document defines an optional, transitive BGP attribute for
   announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
   information and the specification for SR-MPLS SIDs.

 > I agree this is better but will leave out the "labeled" since the attribute could be extended in the
 
[Bruno] Agreed. Thanks.
In the same spirit, you may want to revisit the following text from §6 Error Handling

"   When a BGP Speaker receives a BGP Update message containing a
   malformed or invalid BGP Prefix-SID attribute attached to a IPv4/IPv6
   Labeled Unicast prefix [RFC8277], it MUST ignore the received BGP
   Prefix-SID attributes and not advertise it to other BGP peers."
 
And possibly also the following text:
"  The BGP Prefix-SID attribute defined in this document can be attached
   to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast
   ([RFC4760], [RFC8277]).  Usage of the BGP Prefix-SID attribute for
   other Address Family Identifier (AFI)/ Subsequent Address Family
   Identifier (SAFI) combinations is not defined herein but may be
   specified in future specifications."

I think that what is meant, is that the "Label-Index TLV"  and "Originator SRGB TLV" may be attached to BGP IPv4/IPv6 Labeled Unicast  ([RFC4760], [RFC8277]) routes.

 > A previous review asked for expansion of AFI/SAFI. I will change the order to "BGP IPv4/IPv6
 > Labeled Unicast" consistent with AFI/SAFI throughout.
 
[Bruno] Thanks.

 > Since I've defined SR domain more precisely, I will replace the unqualified "domain" with "AS" in
 
[Bruno] Looks better, thanks.
 
 > No - I mean a global SID which is an index into the SRGB.
 
[Bruno] OK, you are correct.

 > No - it is the scope of the global SID assignment.
 
[Bruno] OK
 
 >     may be :s/global SID assignment/domain wide SID assignement"
 
[Bruno] OK
 
 > You don't think it is clear that the "segment routed path" uses SR segments for routing???

[Bruno] To be honest, I don't really get what this sentence is supposed to specify.
First; what does "should be used" means? Is this supposed to influence any decision? Which one? At best, I could understand "may be used"
Second, for SR-MPLS, which is the only scope of this document, we are talking about the regular MPLS LSP. Nothing really new except a best effort to keep the label unchanged...assuming that the SRGB is the same on all nodes. We may call it "segment", but it's not "routed" any differently.
I'll leave the terminology to you, but I'd welcome a clarification on what the is standardized behavior specified by this sentence.

 > I'm going to retain the hierarchy since separating out the MPLS specific part will make it more
 > straight forward to extend the document to SRv6 in the future.

[Bruno] OK, assuming that in the previous comment, the sentence has some real meaning/impact on the technical specification.
Otherwise the following change seems to cover both your comment and mine:

OLD:
2.  BGP-Prefix-SID

   The BGP Prefix-SID advertised for BGP prefix P indicates that the
   segment routed path should be used (as described below) if the BGP
   best path selects the corresponding Network Layer Reachability
   Information (NLRI).

2.1.  MPLS BGP Prefix SID

NEW:

2.  MPLS BGP Prefix SID

 > I don't want to change this since I believe it was Alvaro who asked for "label index" in a previous

[Bruno] OK, makes sense.

 > What are you suggesting? This is just setting the context for the two alternatives for SRGB
 > advertisement and indicating that BGP-LS is the preferred one for TE in the general sense. If this a
 > rat-hole that will result in much debate, I could remove both these statement relating to traffic
 > engineering as they are not required for the normative specifications in this document.
 
[Bruno] 
From a technical standpoint, I believe that the point is that: the SRGB is needed if global segments are stacked below the BGP segment, e.g. for traffic engineering purpose.
This is a bit different as saying the SRGB is required for TE, as arguably BGP-EPE is TE, but as it uses local segment, we don't need the SRGB.

I'm suggesting:
OLD:
      If the BGP speakers are not all configured with the same SRGB, and
      if traffic-engineering within the SR domain is required, each node
      may be required to advertise its local SRGB in addition to the
      topological information.

 NEW:
      If a global segment is stacked below the BGP segment, e.g. for traffic engineering purpose, the knowledge of the SRGB of the originator of the prefix Segment is required in order to compute the local label used by the originator.

(please feel free to rephrase)

 > Ok - I now reference draft-ietf-spring-segment-routing-mpls.

[Bruno] ok, thanks.

 > I agree. Given the whole section described the BGP Prefix-SID attribute, this paragraph can be
 
[Bruno] agreed, thanks
 
 > I'd leave it in to simplify extension to the SRv6 data plane with a subsequent document.

[Bruno] ok.

 >             by 3 octets specifying the number of labels in the range.
 
[Bruno]  Thanks for accommodating the nitpicking.

 > Someone asked for an examples way back in the review process (way before I had taken over as
 > editor). However, I will change this to a  reference to the SR-MPLS document.
 > 
 > 
 > 
 > ------ OLD:
 
 [Bruno] even better (obviously ;-) ). Thanks.

 > RFC 5004 dampens the rate at which BGP changes the best-path. This was also one of Alvaro's
 
[Bruno] IMO, the label index being used should be the one from best path selected by BGP.
Changing the rate/way the best path is computed is orthogonal to be.
That being said, that specification is just _trying_ to allocate/use the same label, but does not rely on using the same label. So I picking any label may just work... well at least for SR-MPLS, while this part is more generic.
So up to you.
 
 > Although you are the first person to misinterpret this, I will replace "message" with "error log
 > message" to avoid confusion with BGP protocol messages.

[Bruno] Thanks. Indeed, I had interpreted it as BGP message (following "excessive BGP updates")

Many thanks,
--Bruno
 
 > Acee

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 Jun 2018 12:04:20 -0700

On June 14, 2018 at 4:27:49 PM, Acee Lindem (acee) ([email-masked]) wrote:

Acee:

Hi!

Although the use cases for flags relating to these specific TLVs should be
few and far between, I anticipate there will be continued FCFS registry
attack trepidation. I'll change them to expert review.

I’m ok with this change.  Please remember to put in guidelines for the
experts to consider.

Also, this document is scheduled on next week’s IESG Telechat.  Because
some ADs start their reviews over the weekend, do you think you can have an
update ready today/tomorrow?

Thanks!!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 Jun 2018 12:06:13 -0700

Hi!

Never mind about the update, I see you already sent it in!  Thanks!!  :-)

…but we do still need guidance for the Designated Experts.

Thanks!

Alvaro.

On June 15, 2018 at 3:04:20 PM, Alvaro Retana ([email-masked])
wrote:

Also, this document is scheduled on next week’s IESG Telechat.  Because
some ADs start their reviews over the weekend, do you think you can have an
update ready today <http://airmail.calendar/2018-06-15 12:00:00 EDT>
/tomorrow?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Jun 2018 19:17:37 +0000

Hi Alvaro,

From: Alvaro Retana <[email-masked]>
Date: Friday, June 15, 2018 at 3:09 PM
To: Acee Lindem <[email-masked]>, Bruno Decraene <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>, Donald Eastlake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IDR List <[email-masked]>, Routing Directorate <[email-masked]>
Subject: Re: [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

Hi!

Yes – spent a lot of time on this yesterday on document the second time around.

If these appointees are, in fact, experts then why do they require guidance??? I can surely provide some but I think this is just perfunctory bull. Note that there is no “guidance” in https://tools.ietf.org/html/rfc7794

Thanks
Acee

Thanks!

Alvaro.

On June 15, 2018 at 3:04:20 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:
I’m ok with this change.  Please remember to put in guidelines for the experts to consider.

Also, this document is scheduled on next week’s IESG Telechat.  Because some ADs start their reviews over the weekend, do you think you can have an update ready today<http://airmail.calendar/2018-06-15%2012:00:00%20EDT>/tomorrow?

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Jun 2018 19:19:02 -0400

Acee:

I think you underestimate your good sense.  Why don’t you respond to this email with text you’ll put in for expert guidance?  I’m sure you’ll get some comments on it.  

Sue 

From: rtg-dir [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Friday, June 15, 2018 3:18 PM
To: Alvaro Retana; Bruno Decraene; Acee Lindem (acee); Donald Eastlake
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

Hi Alvaro, 

Hi!

If these appointees are, in fact, experts then why do they require guidance??? I can surely provide some but I think this is just perfunctory bull. Note that there is no “guidance” in  <https://tools.ietf.org/html/rfc7794> https://tools.ietf.org/html/rfc7794

Thanks

Acee

Thanks!

Alvaro.

On June 15, 2018 at 3:04:20 PM, Alvaro Retana ([email-masked]) wrote:

Also, this document is scheduled on next week’s IESG Telechat.  Because some ADs start their reviews over the weekend, do you think you can have an update ready  <http://airmail.calendar/2018-06-15%2012:00:00%20EDT> today/tomorrow?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Jun 2018 23:21:28 +0000

In good time Sue, in good time…
Acee

From: Susan Hares <[email-masked]>
Date: Friday, June 15, 2018 at 7:19 PM
To: "'Acee Lindem (acee)'" <acee=[email-masked]>, Alvaro Retana <[email-masked]>, Bruno Decraene <[email-masked]>, 'Donald Eastlake' <[email-masked]>
Cc: IDR List <[email-masked]>, Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21
Resent-From: <[email-masked]>
Resent-To: Stefano Previdi <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <[email-masked]>, John Scudder <[email-masked]>, Susan Hares <[email-masked]>, Jie Dong <[email-masked]>, Martin Vigoureux <[email-masked]>, Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>, Susan Hares <[email-masked]>, John Scudder <[email-masked]>
Resent-Date: Friday, June 15, 2018 at 7:19 PM

Acee:

Sue

Hi Alvaro,

Hi!

Thanks
Acee

Thanks!

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 16 Jun 2018 00:31:53 +0000

Hi Bruno,

See inline.

On Jun 15, 2018, at 12:14 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Acee,

Hi Bruno,

See replies inline.

On 6/13/18, 1:53 PM, "Bruno Decraene" <[email-masked]<mailto:[email-masked]>> wrote:

   Reviewer: Bruno Decraene
   Review result: Has Nits

    Hello,

   § IANA consideration

[Bruno]

  circumstances only.”

You probably saw my response to Alvaro and know that I think the requirement for guidance is bull. However, I’ve never been weak in this domain and would suggest the following:

The designated experts must be good and faithful stewards of the above registries,
assuring that each request is legitimate and corresponds to a viable use case. Given
the limited number of bits in the flags registries and the applicability to a single TLV,
additional scrutiny should be afforded to flag bit allocation requests. In general, no
single use case should require more than one flag bit and, should the use case
require more, alternate encodings using new TLVs should be considered.

Since the BGP Prefix-SID attribute could be extended in the future to SRv6, I don't want to make
such distinction.

OLD:

NEW

Ok. I will add this to the abstract in the -25 version.

   Rationals:

I agree this is better but will leave out the "labeled" since the attribute could be extended in the
future.

[Bruno] Agreed. Thanks.

Since this is the Prefix-SID attribute, I think “prefix” is as clear as “route”. For these AFI/SAFI combinations, I really don’t see that there is any ambiguity here as “routes” and “prefixes” are often used interchangeably. However, given your preference and the fact that they are used interchangeably, I will use route in these two paragraphs.

   But up to the authors.

   -----
   §1

Agreed.

   Proposed NEW:

[Bruno] Thanks.

   -----

Since I've defined SR domain more precisely, I will replace the unqualified "domain" with "AS" in
this sentence.

   (for the same reason)

   BTW2
   "An SR domain

[Bruno] OK

   BTW3
   "An SR domain

No

[Bruno] OK

   -----
   OLD

   Proposed NEW:

Agreed.

   ---

Ok - see below.

OLD:
2.  BGP-Prefix-SID

2.1.  MPLS BGP Prefix SID

NEW:

2.  MPLS BGP Prefix SID

Joyeux anniversaire tôt - I will go with this and remove the troublesome paragraph above.

I don't want to change this since I believe it was Alvaro who asked for "label index" in a previous
review.

[Bruno] OK, makes sense.

   -----

Agreed.

   ------

[Bruno]

I'm suggesting:
OLD:

NEW:

Ok.

   ---

[Bruno] ok, thanks.

I agree. Given the whole section described the BGP Prefix-SID attribute, this paragraph can be
removed.

[Bruno] agreed, thanks

   ---

[Bruno] ok.

   SR-ISIS:

            Range: 3 octets.

   -----

   -----

            SRGB = [100, 199]
                   [1000, 1099]
                   [500, 599]

               index=0 means label 100
               ...
               index 99 means label 199

------ OLD:

I think it is good to have application of RFC 7606 specified explicitly. I have updated as you
proposed.

   proposed NEW:

I agree this is better and consistent with my desire not to preclude extension to SRv6 or other
address families.

   ----
   OLD:

   ---

RFC 5004 dampens the rate at which BGP changes the best-path. This was also one of Alvaro's
comments.

I’m going to leave it since this is based on a previous comment from a BGP implementor. In the words of Abraham Lincoln, “You can’ t please all the people all the time.” Expect the other changes in the -25 version.

Thanks,
Acee

"It should be

   -----

Many thanks,
--Bruno

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 16 Jun 2018 00:49:00 +0000

Hi Bruno,

From: Acee Lindem <[email-masked]>
Date: Friday, June 15, 2018 at 8:32 PM
To: Bruno Decraene <[email-masked]>
Cc: IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Routing Directorate <[email-masked]>
Subject: Re: Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21
Resent-From: <[email-masked]>
Resent-To: Stefano Previdi <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <[email-masked]>, John Scudder <[email-masked]>, Susan Hares <[email-masked]>, Jie Dong <[email-masked]>, Martin Vigoureux <[email-masked]>, Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>, Susan Hares <[email-masked]>, John Scudder <[email-masked]>
Resent-Date: Friday, June 15, 2018 at 8:32 PM

Hi Bruno,

See inline.

Hi Acee,

Hi Bruno,

See replies inline.

   Reviewer: Bruno Decraene
   Review result: Has Nits

    Hello,

   § IANA consideration

[Bruno]

OLD:

NEW

   Rationals:

[Bruno] Agreed. Thanks.

Actually, I’m not going to change this as this would permeate throughout the document and certainly wouldn’t want Alvaro to send the document back to the WG for a third time.

Thanks,
Acee

 But up to the authors

   -----
   §1

Agreed.

   Proposed NEW:

[Bruno] Thanks.

   -----

   (for the same reason)

   BTW2
   "An SR domain

[Bruno] OK

   BTW3
   "An SR domain

No

[Bruno] OK

   -----
   OLD

   Proposed NEW:

Agreed.

   ---

Ok - see below.

OLD:
2.  BGP-Prefix-SID

2.1.  MPLS BGP Prefix SID

NEW:

2.  MPLS BGP Prefix SID

[Bruno] OK, makes sense.

   -----

Agreed.

   ------

[Bruno]

I'm suggesting:
OLD:

NEW:

Ok.

   ---

[Bruno] ok, thanks.

[Bruno] agreed, thanks

   ---

[Bruno] ok.

   SR-ISIS:

            Range: 3 octets.

   -----

   -----

            SRGB = [100, 199]
                   [1000, 1099]
                   [500, 599]

               index=0 means label 100
               ...
               index 99 means label 199

------ OLD:

   proposed NEW:

   ----
   OLD:

   ---

Thanks,
Acee

"It should be

   -----

Many thanks,
--Bruno

Thanks,
Acee

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 09:02:26 +0000

Hi Acee,

Looks perfect.
Thanks.

--Bruno

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Saturday, June 16, 2018 2:32 AM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Rtgdir last call review of draft-ietf-idr-bgp-prefix-sid-21

Hi Bruno,

See inline.

Hi Acee,

Hi Bruno,

See replies inline.

   Reviewer: Bruno Decraene
   Review result: Has Nits

    Hello,

   § IANA consideration

[Bruno]

OLD:

NEW

   Rationals:

[Bruno] Agreed. Thanks.

   But up to the authors.

   -----
   §1

Agreed.

   Proposed NEW:

[Bruno] Thanks.

   -----

   (for the same reason)

   BTW2
   "An SR domain

[Bruno] OK

   BTW3
   "An SR domain

No

[Bruno] OK

   -----
   OLD

   Proposed NEW:

Agreed.

   ---

Ok - see below.

OLD:
2.  BGP-Prefix-SID

2.1.  MPLS BGP Prefix SID

NEW:

2.  MPLS BGP Prefix SID

[Bruno] OK, makes sense.

   -----

Agreed.

   ------

[Bruno]

I'm suggesting:
OLD:

NEW:

Ok.

   ---

[Bruno] ok, thanks.

[Bruno] agreed, thanks

   ---

[Bruno] ok.

   SR-ISIS:

            Range: 3 octets.

   -----

   -----

            SRGB = [100, 199]
                   [1000, 1099]
                   [500, 599]

               index=0 means label 100
               ...
               index 99 means label 199

------ OLD:

   proposed NEW:

   ----
   OLD:

   ---

Thanks,
Acee

"It should be

   -----

Many thanks,
--Bruno

Thanks,
Acee

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 09:04:59 +0000

Hi Acee,

Sent: Saturday, June 16, 2018 2:49 AM

Hi Bruno,

Hi Bruno,

See inline.

Hi Acee,

Hi Bruno,

See replies inline.

   Reviewer: Bruno Decraene
   Review result: Has Nits

    Hello,

   § IANA consideration

[Bruno]

OLD:

NEW

   Rationals:

[Bruno] Agreed. Thanks.

[Bruno2]
Works for me.
Thanks
--Bruno
Thanks,
Acee

 But up to the authors

   -----
   §1

Agreed.

   Proposed NEW:

[Bruno] Thanks.

   -----

   (for the same reason)

   BTW2
   "An SR domain

[Bruno] OK

   BTW3
   "An SR domain

No

[Bruno] OK

   -----
   OLD

   Proposed NEW:

Agreed.

   ---

Ok - see below.

OLD:
2.  BGP-Prefix-SID

2.1.  MPLS BGP Prefix SID

NEW:

2.  MPLS BGP Prefix SID

[Bruno] OK, makes sense.

   -----

Agreed.

   ------

[Bruno]

I'm suggesting:
OLD:

NEW:

Ok.

   ---

[Bruno] ok, thanks.

[Bruno] agreed, thanks

   ---

[Bruno] ok.

   SR-ISIS:

            Range: 3 octets.

   -----

   -----

            SRGB = [100, 199]
                   [1000, 1099]
                   [500, 599]

               index=0 means label 100
               ...
               index 99 means label 199

------ OLD:

   proposed NEW:

   ----
   OLD:

   ---

Thanks,
Acee

"It should be

   -----

Many thanks,
--Bruno

Thanks,
Acee