Subject: [Idr] Martin Vigoureux's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMMENT)

From: Martin Vigoureux <[email-masked]>
Date: Thu, 21 Jun 2018 05:19:52 -0700

Martin Vigoureux has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: No Objection

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

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

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

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

Hello,

thank you for this Document.
I have few comments:

Abstract:
references to "service chain" were removed from SPRING originated documents.
Should we do the same here?

1. Introduction
It looks to me that these two definitions are not identical. Should only one be
kept?
   A group of inter-connected nodes that use SR forms an SR domain.
   An SR domain is defined as a single administrative domain for global SID
   assignment.
On that matter, I am not sure it is worth restating a definition further down
"(i.e., the set of Autonomous Systems under a common administration and control
and where SR is used)"

Aren't these two sentences somehow in conflict (i.e. "always global" Vs. "MAY
be global"):
   A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing])
   within the SR domain A BGP Prefix-SID MAY be global across ASes when the
   interconnected ASes agree on the SID allocation scheme.
I make the assumption that "interconnected ASes" which "agree on the SID
allocation scheme" form an SR domain, but I may be wrong.

s/we always refer to the BGP segment by the BGP Prefix-SID/we always refer to
the BGP-Prefix segment by the BGP Prefix-SID/ ?

   A BGP Prefix-SID MAY be attached to a prefix.
Do you mean a "A Prefix-SID MAY be attached to a BGP-Prefix" or do you mean "A
BGP Prefix-SID attribute MAY be attached to a BGP IPv4/IPv6 Label Unicast
prefix" ? I would say the latter but that sentence: "A BGP-Prefix Segment is a
BGP prefix with a Prefix-SID attached" (found couple of paragraphs above) makes
me doubt.

3.1.  Label-Index TLV
   It MUST be ignored when received for other BGP AFI/SAFI combinations.
Is that constraint needed? I am asking because in the Introduction you seem to
at least allow for other AFI/SAFI to use the BGP Prefix-SID.

3.2.  Originator SRGB TLV
Same comment as above this time for the Originator SRGB TLV

s/The originator SRGB/The Originator SRGB TLV/ (twice)

7.  IANA Considerations
   This document defines 3 TLVs for the BGP Prefix-SID attribute.
I guess that's a leftover from the IPv6 years. I only see two TLVs defined.

   2     Deprecated      this document
Would it be worth to document why this is indicated as being deprecated? I
understand that this was assigned to IPv6 SID TLV in earlier versions of the
Document and that the Document now leaves v6 oos, but I guess it wouldn't hurt
to have a couple of sentences.

Thank you

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 14:18:37 +0000

Hi Martin, 

I have incorporated most of them. See inline. 

On 6/21/18, 8:19 AM, "Martin Vigoureux" <[email-masked]> wrote:

    
    
    Hello,

    Abstract:

Sure. I've taken the updated definition from the first 2 statements in the SR architecture.
    
    1. Introduction

Good point. I will only retain the second definition. 

You are correct - I have reworded the second sentence. 

    A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same SR domain.

Fixed.

This has always meant to be a general statement. The BGP Prefix-SID may be extended to other AFs. I will change "prefix" to "BGP-Prefix" rather than only references the specified AFs since these statements are applicable independent of AF. 
    
    3.1.  Label-Index TLV

This will hold true until the usage is extended through a new specification. 
    
    3.2.  Originator SRGB TLV

Same response. 

Fixed.

    7.  IANA Considerations

Good Catch. 

And why is this of value in the final document? You are the second person to suggest this might be useful so I will add something at the risk of more questions. 

Thanks,
Acee 

    Thank you

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 21 Jun 2018 17:04:53 +0200

Acee,

many thanks for quick response and for addressing my comments.
Few reactions in-line as a follow-up.

-m

>      https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/
[...]
>      Same comment as above this time for the Originator SRGB TLV

For these two points, my reasoning was that
* by writing down that sentence you somehow impose to any future 
document -which would use these TLVs for other AFI/SAFI- to Update that 
current one, and that seems unnecessary.
* and setting that constraint seems a bit contradictory to the fact that 
other AFI/SAFI are oos of this document.
But I can live with it.

[...]

> And why is this of value in the final document? You are the second person to suggest this might be useful so I will add something at the risk of more questions.
It's not so much about adding value but answering a question the reader 
might have when reading this. I haven't looked at the creation 
statements of all registries that exist, but marking a value as 
Deprecated at the exact time it is registered seems unusual.