Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31

"Adrian Farrel" <> Mon, 03 April 2017 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 436B21294FF for <>; Mon, 3 Apr 2017 13:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9aL7hXSnt1VD for <>; Mon, 3 Apr 2017 13:13:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1694F120726 for <>; Mon, 3 Apr 2017 13:13:48 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id v33KDkF1005837; Mon, 3 Apr 2017 21:13:46 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v33KDeBR005814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Apr 2017 21:13:43 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Susan Hares'" <>, "'idr wg'" <>
References: <035901d2a263$a204a0c0$e60de240$>
In-Reply-To: <035901d2a263$a204a0c0$e60de240$>
Date: Mon, 3 Apr 2017 21:13:41 +0100
Message-ID: <03d201d2acb6$cbde3b10$639ab130$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D3_01D2ACBF.2DA9CF00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJy9qBC8F701cXQis495LO0YAEVQ6BzgAOQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--6.196-10.0-31-10
X-imss-scan-details: No--6.196-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkADJrf2+hNOhR/XcAla9LsVGSqdEmeD/nUJW4Re2U2pywLy tDvV39h+akWhnG4LWFMe1dimxk/EMQt3e7z0WipRaK+MsTwM+1nRahuPwaQ1Wp34fb7E2X5X678 QLKEvGo5ScMO53ropjOltpAMjEbBlDkubg39L7f92aFFWhkT3QIfGLZ++QpQzV9eB8vnmKe8mTu 1wNQz7bWpGhHN2hzD2rTHRCIAhqg5ksv7qaWt2jLMjW/sniEQKKVrLOZD1BXR/tE9YIUrwYv688 b7UXBa5hh+zDuoppuIeyhqogscOqfazQK8vdF3c85L5JHGOAXB6+4H1+M9GHpGntM3CLyHIjKcD Q/TrHaTgTqW7m1ORTxOiym2ygFHRyi3rT9eHsAHi3aa5wOREEYHTV2uJaSjbbM3UnqznDLYtjYL FZ2xmSlKRkLRcLF1LPxGNUiN+AyYXa+syOp067QXysW33GYMpYY0tNGdvli2VCgMHKlN03W5n3p /PBaJMhKLPzEV+09FwoI7ADD6NSAvuBkbttOji6ivQ8oO6nUJvibOW4IkXhD6IXkgHUCXL8z70X DTUjsY0gGvDuBPXdGHbb7mQgkX3IfPTd+OTqvFGypC5CVFOH2cuTq1AtxjpT7S4ZU4XTxDz/Kux bhpDT9NQo22x5OZQVdG7zs0JFFSBnJ5ETtWXfUKcYi5Qw/RVF2pUb6YRYK61eX0jEQ9c6okuTXu Mw1pdzI5U2cfi+8cdJWgVhit1DrqrIFIJwJ9i71Wx2uUbPLdDr8MVm6DK3TA4N9SXuYkp/hkBSy 3LYQ17CjyP3UZ5MbpGAQ2wD/3Qyx6w4CJ+2uWeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXl6hn76fRjuIZa9wiplIRXXmL4Mlh72yBVMye5OHmDzLpc0aJbFHlIQV6vLex6ViMPBQZIV vM9P+z0SyaQKAWrtEJdFpPV7T/gIiuF7tZeAlExlQIQeRG0=
Archived-At: <>
Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Apr 2017 20:13:53 -0000

Hi Sue, WG,
Yes, sorry for not getting to this the first time around.
It's a good piece of work that needs to be standardised, and this document is
ready modulo the relatively small comments below.
=== Code point stuff ===
I thought we had some fairly good clue in IDR about not "suggesting"
code point values, but in section 4 I found...
   The BGP Prefix SID attribute is an optional, transitive BGP path
   attribute.  The attribute type code is to be assigned by IANA
   (suggested value: 40).
As it turns out, an early allocation has been done and is recorded in
section 8. So this text should read...
   The BGP Prefix SID attribute is an optional, transitive BGP path
   attribute.  The attribute type code 40 has been assigned by IANA
   (see Section 8).
=== Rambling Thoughts ===
Section 4.2
      *  S flag: if set then it means that the BGP speaker attaching the
         Prefix-SID Attribute to a prefix is capable of processing the
         IPv6 Segment Routing Header (SRH,
         [I-D.ietf-6man-segment-routing-header]) for the segment
         corresponding to the originated IPv6 prefix.  The use case
         leveraging the S flag is described in
Suppose that sometime in the future a third type of SID processing is
defined. Well, you'd burn a new bit, say the X bit, to indicate the
support of that method. But how would you set the S bit in that case?
So, perhaps you need two bits already.
=== Minor ===
Odd to reference draft-ietf-6man-segment-routing-header but not
I think draft-ietf-spring-segment-routing and draft-ietf-spring-segment-
routing-msdc are normative references based both on the importance as
background material and the text in the first paragraph of the document.
The material in Section 1 suggests that draft-ietf-spring-segment-
routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe might
also be normative references.
The RFC Editor will require that the first section of the document is
the "Introduction".  I think you fix this by moving the current Section
1 to be a sub-section of the current Section 2.
I wish we (or the SPRING WG) would nail down the terminology of a
"segment" and a "segment identifier." This muddiness is just not
necessary, but is perpetrated by this document saying that
  The ingress node of the SR domain prepends a (sic) SR
  header containing "segments" to an incoming packet.
but then saying that
  Each segment is identified by a Segment Identifier (SID).
So, in fact, the SR header contains SIDs not segments.
This confusions is continued by
  Each segment represents a topological instruction
Do segments *represent* topological instructions or are they
topological instruction?
Section 2 has...
   A BGP-Prefix-SID is always global within the SR/BGP domain
While this language is clear from the referenced documents, it is not
very clear in this document. I think you need to say ...
   A BGP-Prefix-SID is always a global SID [I-D.ietf-spring-segment-
   routing] within the SR/BGP domain
...although (of course) draft-ietf-spring-segment-routing talks about
global segments but not global SIDs except in 3.1.3 where the mention
is a little without context.
Section 3.1 has...
      While it is recommended to use the same SRGB across
      all the nodes within the SR domain, the SRGB of a node is a local
      property and could be different on different speakers.
I *think* that this recommendation comes from the referenced document
[I-D.ietf-spring-segment-routing] and not from this current document.
This would be clearer by writing...
      While [I-D.ietf-spring-segment-routing] recommends to use the same
      SRGB across all the nodes within the SR domain, the SRGB of a node
      is a local property and could be different on different speakers.
Doing this will stop questions about whether "recommended" is supposed
to be in 2119 upper case.
In 3.1...
      The index L_I is a 32 bit offset in 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.
Is this right or is L_I, as defined in draft-ietf-spring-segment-
routing-mpls, a 20 bit offset into a reduced 20-bit space out of the 32-
bit SID space?
FWIW, this section is another place I would have expected to see a
reference to draft-ietf-spring-segment-routing-mpls.
First para of section 4 ends...
   The value field of the BGP-Prefix-SID
   attribute has the following format:
Is there supposed to be a figure here? The next paragraph doesn't seem
to flow. Maybe this sentence can be deleted.
Are you sure you don't want a registry for flags?
   A BGP speaker may be locally configured with an SRGB=[GB_S, GB_E].
Probably "MAY"?
I think that the notation needs some small explanation.
   The Label Index gives a hint to the receiving node on which
   local/incoming label the BGP speaker SHOULD use.
This is like a double SHOULD: "hint" and "SHOULD use".
It might be helpful to describe the potential variance.
   In order to
   prevent distribution of the BGP Prefix-SID attribute beyond its
   intended scope of applicability, attribute filtering MAY be deployed.
Yeah. That's OK, but the language implies there are other ways to prevent
distribution beyond the intended scope.
   all the occurrences of
   the attribute other than the first one SHALL be discarded and the BGP
   Update message shall continue to be processed.
I think the second "shall" is a "SHALL" as well.
=== Nits ===
The authors need to sort out their affiliations and email addresses.
The AD will probably not be happy with 7 names on the front page.
s/This informations/This information/
4.1 and 4.3
s/None are/None is/
   When a SR IPv6 BGP speaker receives a IPv6 Unicast BGP Update with
s/a/an/ x2
s/[RFC3107]or/[RFC3107] or/
s/([RFC3107])The/([RFC3107]).  The/
Section 11 might possibly be of no value.
From: Idr [] On Behalf Of Susan Hares
Sent: 21 March 2017 16:53
To: 'idr wg'
Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6
to 3/20/2017 - extending to 3/31
Perhaps the WG LC came at a bad time since have received only 1 response.  We
will length the call to 3/31.  Unless with have substantial input, this WG LC
will not indicate consensus. 
Sue Hares