Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-prefix-sid

["Acee Lindem (acee)" <[e-mail]>]

Hi Tony, 

Thanks for the review - see inline. I've prepended "Acee>" to my response.

On 2/2/18, 11:58 PM, "Antoni Przygienda" <[e-mail]> wrote:

    I have been selected to do a routing directorate “early” review of draft-ietf-idr-bgp-prefix-sid  draft.
    
    Document: draft-ietf-idr-bgp-prefix-sid
    Reviewer: Tony Przygienda
    Review Date: 1/30/18
    Intended Status: Standards Track
    
    Summary:
    Choose from this list...
    
    I have some comments about this document that I think should be resolved before it is submitted to the IESG.
    
    Comments, mostly clarification and readability improvement
    
    1. The introduction would make the document significantly more readable by pointing out that SPRING SID can only be carried over RFC8277 and SRv6 SID only over RFC4760. Yes, it is described later while the elements are described but makes the reading of the draft hard without this information upfront. 

Acee> This is in the sixth paragraph of the introduction. However, I've added:

   Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations
   is not defined herein but may be specified in future specifications.

    2. The sentence “The BGP Prefix-SID attached to a BGP prefix P represents the instruction "go to Prefix P" along its BGP best path (potentially ECMP-enabled)” is confusing and would need rewriting IMO. It is the prefix that advises to go to the prefix by lookup and forwarding obviously (if one would use such language) and not the “prefix sid attached to the prefix”.  Maybe something like “BGP Prefix SID present in the segment list should trigger the action of …. and with that ultimately forward the packet to the prefix the SID is associated with along the best ….”

Acee> I agree and have never had an attachment to this phrasing. Here is what I replaced it with. Feel free to suggest changes. 

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


    3. The document should explain whether 
    a. It is valid to receive Originator SRGB TLV without Label Index TLV being present 

Acee> Since the Label Index TLV is required for labeled unicast AFI/SAFIs, the attribute will not be used in this case. 

I did add this:

   Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability,
   the originator SRGB will be ignored if it is not specified consistent
   with Section 6.

    b. It is valid to receive both SRv6 and SPRING SID for the same prefix 

Acee>I think this is stated since it says either will be ignored for an AFI/SAFI for they are not applicable. 

    c. It is valid to receive SRGB TLV while having obtained it by other topology distribution mechanism and which one has preference

Acee>This alternative is outside the scope of the specification. Feel free to suggest text. Typically BGP is fairly liberal with respect to local policy overriding what is learned. 

    4. The document could explain for readability that it is assumed that multiple ranges in SRGB represent logically speaking really a single range to which the index is applied and not multiple ranges of which one is chosen (yes, it could go a long way to not call everything here range). Or reference an RFC where such a thing is clearly explained. 

Acee>I've added this. 

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

    5. Those two sentences seem to contradict each other directly. “The mechanisms through which a given label index value is assigned to a given prefix are outside the scope of this document.  The label-index value associated with a prefix is locally configured at the BGP node originating the prefix.”

Acee>I removed the second sentence. 

    6. Not English (important for next point)
    a. “The label index gives the information to the receiving node on which local/incoming label the BGP speaker SHOULD assign.”

Acee> Changed to: 
 
   The label index provides the receiving BGP speaker with
   guidance as to the incoming label that SHOULD be assigned by that BGP
   speaker.


    7. The unparsable sentence in point 6. Makes understanding the forwarding behavior difficult. So is the normal MPLS label used and when and for what (except when SID cannot be derived as described)?  If not, why is the null label signaling needed? In fact what does that mean “Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL from a neighbor MUST adhere to standard behavior and program its MPLS dataplane to pop the top label when forwarding traffic to the prefix.  The label NLRI defines the outbound label that MUST be used by the receiving node.”. If we got a NULL and strip what’s there left and what label do we use as the “The label NLRI defines the outbound label” if the label NLRI is implicit NULL. Am I confused?  A small set of examples would go a long way. 

Acee>This is really just RFC 8277.  Reordered the paragraphs appropriately.

  The outgoing label is always programmed as per classic Multiprotocol
   BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation.  Specifically, a
   BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a
   label NLRI field of Implicit NULL from a neighbor MUST adhere to
   standard behavior and program its MPLS dataplane to pop the top label
   when forwarding traffic to the prefix.  The label NLRI defines the
   outbound label that MUST be used by the receiving node.

   The label index provides the receiving BGP speaker with guidance as
   to the incoming label that SHOULD be assigned by that BGP speaker.

Thanks,
Acee