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

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Jeff,

Thanks for your review and comments. Please check and let know if I've got your complete review (it was the same in the IDR archive) since we sometimes see truncation when emails are send out with comments embedded within IDNITs text.

We've posted an update for the draft with comments addressed as clarified in detail inline below.

https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-sbfd-extensions-05.txt

-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: 20 February 2021 23:40
To: [e-mail]; [e-mail]
Subject: Shepherd writeup for draft-ietf-idr-bgp-ls-sbfd-extensions

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.  
[KT] Since the bis document RFC will obsolete RFC7752 when published, would it not be ok to continue using RFC7752 until then? The concern that I have is that these minor BGP-LS extensions are not held up on the publication of 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.
[KT] Ack

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.
[KT] I've update the text to use both in a consistent manner so it is easier to understand from both BFD and TE/SR terminologies perspective for the use-cases under discussion.

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 
[KT] ack

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

level, or
[KT] ack

[...]

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"
[KT] ack

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
[KT] ack

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.
[KT] ack

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"
[KT] Ack

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

"enables creating S-BFD sessions"
[KT] ack

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
[KT] ack

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

Initiator
[KT] ack

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"
[KT] ack

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.
[KT] ack

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
[KT] ack

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"
[KT] ack

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.
[KT] The text in RFC7752 is in the context of the TLVs that go into the NLRI portion. The SBFD Discriminator TLV goes into the BGP-LS Attribute and hence these considerations do not apply for it.

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".
[KT] Please check response to previous comment. In the interest of keeping BGP-LS as simple and "true" to what is being advertised in the IGPs, the current text looks good to me. However, do let know if you feel that we need to handle things differently in this instance.

Thanks,
Ketan