[Idr] Shepherd writeup for draft-ietf-idr-bgp-ls-sbfd-extensions

[Jeffrey Haas <[e-mail]>]

Authors,

Please find attached the shepherd review comments for
draft-ietf-idr-bgp-ls-sbfd-extensions.  The line numbering is from the
ID-nits tool output vs. draft version -04.

Tersely:
- Some suggest grammar and syntax tweaks.  Changes you find contentious can
  be deferred to the authority of the RFC Editor.
- A few changes to use the terminology as specified in the S-BFD RFC.
- One item of major concern is the ordering of the S-BFD Discrimators.
  Please use this thread to respond to how you'd like to address that open
  concern.

I believe once we have addressed these items we can submit this document to
the IESG.

A final item of discussion is we are in the middle of RFC7752-bis work.
While it is my opinion that the -bis work has no implications currently on
the mechanism described in this draft, the authors and Working Group should
consider if they prefer to this mechanism to normatively require the -bis
document.  

-- Jeff

----------------------------------8<--- cut here --->8---------------------------

81	1.  Introduction

83	   Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines
84	   a simplified mechanism to use Bidirectional Forwarding Detection
85	   (BFD) [RFC5880] with large portions of negotiation aspects
86	   eliminated, thus providing benefits such as quick provisioning as
87	   well as improved control and flexibility to network nodes initiating
88	   the path monitoring.

90	   For monitoring of a service path end-to-end via S-BFD, the headend/
91	   initiator node needs to know the S-BFD Discriminator of the

Initiator is the capitalization used in RFC 7880.

92	   destination/tail-end node of that service.  The link-state routing

Responder would be the appropriate term to use here.

I would suggest dropping headend/tail end and simply use Initiator/Responder 
(or Reflector) as per RFC 7880.

93	   protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise
94	   the S-BFD Discriminators.  With this a initiator node can learn the

With this, an Initiator can 

95	   S-BFD discriminator for all nodes within its IGP area/level or

level, or

[...]

123	3.  Problem and Requirement

[...]

133	   boundaries.  This provides a seamless MPLS transport connectivity for
134	   any two service end-points across the entire domain.  In order to
135	   detect failures for such end to end services and trigger faster
136	   protection and/or re-routing, S-BFD MAY be used for the Service Layer
137	   (e.g. for MPLS VPNs, pseudowires, etc. ) or the Transport Layer
138	   monitoring.  This brings up the need for setting up S-BFD session

Suggest "creates the need"

139	   spanning across AS domains.

141	   In a similar Segment Routing (SR) [RFC8402] multi-domain network, an
142	   end to end SR Policy [I-D.ietf-spring-segment-routing-policy] path
143	   may be provisioned between service end-points across domains either
144	   via local provisioning or by a controller or signalled from a Path

provisioning, or

145	   Computation Engine (PCE).  Monitoring using S-BFD can similarly be

While PCE is being used in a very general fashion here, an informational
reference to RFC 4655 may be appropriate.

146	   setup for such a SR Policy.

148	   Extending the automatic discovery of S-BFD discriminators of nodes
149	   from within the IGP domain to across the administrative domain using

"domain across the administrative domain" or "domain to cross an administrative
domain"

150	   BGP-LS enables setting up of S-BFD sessions on demand across IGP

"enables creating S-BFD sessions"

151	   domains.  The S-BFD discriminators for service end point nodes MAY be
152	   learnt by the PCE or a controller via the BGP-LS feed that it gets
153	   from across IGP domains and it can signal or provision the remote

domains, and it

154	   S-BFD discriminator on the initiator node on demand when S-BFD

Initiator

155	   monitoring is required.  The mechanisms for the signaling of the
156	   S-BFD discriminator from the PCE/controller to the initiator node and
157	   setup of the S-BFD session is outside the scope of this document.

"are outside the scope"

159	   Additionally, the service end-points themselves MAY also learn the
160	   S-BFD discriminator of the remote nodes themselves by receiving the
161	   BGP-LS feed via a route reflector (RR) or a centralized BGP Speaker

Suggest informational citation for RFC 4456.

162	   that is consolidating the topology information across the domains.
163	   The initiator node can then itself setup the S-BFD session to the

Initiator

164	   remote node without a controller/PCE assistance.

166	   While this document takes examples of MPLS and SR paths, the S-BFD
167	   discriminator advertisement mechanism is applicable for any S-BFD
168	   use-case in general.

170	4.  BGP-LS Extensions for S-BFD Discriminator

172	   The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of
173	   nodes and their attributes using the BGP-LS Attribute.  The S-BFD
174	   discriminators of a node are considered as its node level attribute
175	   and advertised as such.

177	   This document defines a new BGP-LS Attribute TLV called the S-BFD
178	   Discriminators TLV and its format is as follows:

"TLV, and its"

180	      0                   1                   2                   3
181	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
182	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
183	     |              Type             |             Length            |
184	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
185	     |                         Discriminator 1                       |
186	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
187	     |                    Discriminator 2 (Optional)                 |
188	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
189	     |                               ...                             |
190	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
191	     |                    Discriminator n (Optional)                 |
192	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

194	               Figure 1: S-BFD Discriminators TLV

196	     where:

198	   o  Type: 1032 (early allocation by IANA)

200	   o  Length: variable.  Minimum of 4 octets and increments of 4 octets
201	      there on for each additional discriminator

203	   o  Discriminators : multiples of 4 octets, each carrying a S-BFD
204	      local discriminator value of the node.  At least one discriminator
205	      MUST be included in the TLV.

Here upon deep review, I think we have an interesting item requiring further
discussion and perhaps text.

RFC 7880, section 3, says the following about multiple discriminators:
:    When a node allocates multiple S-BFD Discriminators, how remote nodes
:    determine which of the discriminators is associated with a specific
:    entity is currently unspecified.  The use of multiple S-BFD
:    Discriminators by a single network node is therefore discouraged
:    until a means of learning the mapping is defined.

RFC 7752, section 3.1 says the following about sorting:
:    In order to compare NLRIs with unknown
:    TLVs, all TLVs MUST be ordered in ascending order by TLV Type.  If
:    there are more TLVs of the same type, then the TLVs MUST be ordered
:    in ascending order of the TLV value within the TLVs with the same
:    type by treating the entire Value field as an opaque hexadecimal
:    string and comparing leftmost octets first, regardless of the length
:    of the string.  All TLVs that are not specified as mandatory are
:    considered optional.

Given the above text, it seems like it should be recommended that the list of
Discriminators is sorted.

Where this is potentially problematic is the mapping procedures:

207	   The S-BFD Discriminators TLV can be added to the BGP-LS Attribute
208	   associated with the Node NLRI that originates the corresponding
209	   underlying IGP TLV/sub-TLV as described below.  This information is
210	   derived from the protocol specific advertisements as below..

212	   o  IS-IS, as defined by the S-BFD Discriminators sub-TLV in
213	      [RFC7883].

215	   o  OSPFv2/OSPFv3, as defined by the S-BFD Discriminators TLV in
216	      [RFC7884].

Both of these RFCs extend the hand-waving that was done during the S-BFD
standardization process for "how do you pick one".  The answer at that point of
time was "the implementation will decide", which might normally be fine.  

However, since RFC 7752 has an opinion about how attributes should be presented
for canonicalization purposes, a simple copy-and-paste from the IGP into BGP-LS
may not be appropriate.  And that perhaps impacts a proprietary scheme; e.g.
"pick the first one in the set".