Subject: Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

From: Paolo Lucente <[email-masked]>
Date: Thu, 11 Jul 2019 12:30:53 +0000

Hi Jeff,

Thanks very much for these comments. I believe i did my best to process them, you can see the commit log here:

https://github.com/paololucente/draft-ietf-grow-bmp-loc-rib/commit/d5a042b3c5251d87bf8b66bb5cd3554bb5cee128

Inline:

On 12 Jun 2019, at 23:29, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

[ .. ]

Section 1 - Introduction:
The introduction provides a description about the problems with how one
gathers data today, including RFC 7854 local view and compares issues
(beginning in the text "The current method") that impede standard RFC 4271
BGP (plus extensions) from being used to monitor a router.  The introduction
really needs a few sentences at the top giving a positive statement of what
this draft is trying to accomplish.  An example of this would be:
"This document defines a mechanism to monitor the BGP Loc-Rib state for
multiple BGP instances without the need for one or more unneeded BGP peering
sessions."  The rest of the introduction provides the justification.

Done as per your suggestion.

"the BGP instance" doesn't have any RFC context associated with it.  RFC 7854
makes some discussion about multi-instancing of BGP in section 8.1.  I'd
suggest you define this somewhere in a terminology section as "an instance
of BGP-4 (RFC 4271)" or similar, with the related pointer to the 7854
multi-instance comment.

Done, added a “BGP Instance” in the Definitions section. Unfortunately by then the “BGP Instance” term is repeated already a few times in Abstract and Introduction.

: As shown in Figure 2, Locally originated follows a similar flow where
: the redistributed or otherwise originated routes get installed into
: the Loc-RIB based on the decision process selection.

I'd suggest a pointer to RFC 4271, section 9.4 here.

Done.

: BGP instance Loc-RIB usually provides a similar, if not exact,
: forwarding information base (FIB) view of the routes from BGP that
: the router will use.

The BGP spec doesn't mention a FIB at all.  The interaction with the rest of
the system is via the Routing Table.  (RFC 4271, section 3.2)  I'd either
normalize the text to use that, or delete references to the FIB.

Done, deleted.

Section 2, as noted elsewhere, should likely use RFC 8174 these days.

Done.

Section 3:
Loc-RIB definition - please point to 4271 section 9.4

Done.

Section 5:
:  Loc-RIB contains all routes from BGP peers as well as any and all
:  routes redistributed or otherwise locally originated.  In this
:  context, only the BGP instance Loc-RIB is included.  Routes from
:  other routing protocols that have not been redistributed, originated
:  by or into BGP, or received via Adj-RIB-In are not considered.

I'd suggest the following:
"The Loc-RIB contains all routes selected by BGP's Decision Process (RFC
4271, section 9.1).  These routes include those learned from BGP peers via its
Adj-RIBs-In post-policy, as well as routes learned by other means.  (RFC
4271, section 9.4) Examples of these include redistribution of routes from
other protocols into BGP, or otherwise locally originated; e.g. aggregate
routes.”

Done.

:  Loc-RIB in this context does not attempt to maintain a pre-policy and
:  post-policy representation.  Loc-RIB is the selected and used routes,
:  which is equivalent to post-policy.
:
:  For example, VRF "Blue" imports several targets but filters out
:  specific routes.  The end result of VRF "Blue" Loc-RIB is conveyed.
:  Even though the import is filtered, the result is complete for VRF
:  "Blue" Loc-RIB.  The F flag is not set in this case since the Loc-RIB
:  is complete and not filtered to the BMP receiver.

The above feels awkward.  I've tried to remove the need for this text by
noting "post-policy" in the suggested text above.

The second paragraph above is structured to try to discuss when the F-bit is
used.  I'd suggest instead that section 4.2 add a new sentence describing
that the F-bit is only set when a subset of the Loc-Rib is sent on the BMP
session and not when BGP routes are excluded from the Adj-Ribs-In based on
policy.

Done, removed text and example and added text to section 4.2.

Section 5.1:
s/filed/filled/

Done.

Peer BGP ID: It's fine for this document to shorten this to BGP ID, but a
reference should be made to "BGP Identifier".  (RFC 4271, section 1.1; RFC 6826)

Done.

Section 5.2/5.3:
Per prior discussion in other threads, it should be noted that changes that
result in an alteration of behavior need a PeerDown/PeerUp bounce along with
re-sync of routes.  I believe this may only include a change to the F-bit in
the current specification.

Done, added section 6.1.3 about “Changes to existing BMP sessions” under Other Considerations.

Section 5.5:
It might be worth mentioning that route mirroring messages MAY/SHOULD be
ignored.  However, it might not be worth mentioning.  It's not like we'll
bounce the session as long as things parse?  (But we've seen protocol
pedantry where that would be a valid behavior….)

Done.

Section 6.1.1/6.1.2:
6.1.2 clearly talks about filtering.  6.1.1 talks about multiple peers,
perhaps split on things like address family.  For clarity, this section
may want to discuss options for multiple views for filtering.

For example, consider two distinct views: ebgp peers, ibgp peers.  Or
"customers" and "infrastructure".

I believe the text as written suggest it'd be fine to have multiple views,
each filtered, each using the same peer distinguisher and BGP ID.  However,
they may wish to be distinguished using a Table Name; e.g.

Done. This opened a further consideration at my end. The document lacks a statement as in https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about “TLVs can be sent in any order. Multiple TLVs of the same type can be repeated as part of the same message and it is left to the specific use-cases whether all, any, the first or the last TLV should be considered.”. In the specific case of VRF/Table Name one could have both a VRF id/name and a Table Name, hence the same TLV could be repeated twice (my take is that it’s a perfectly valid scenario). I’d tackle this case once i get green light from you that we are good about how your feedback was processed.

Paolo

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Jul 2019 08:55:07 -0400

Paolo,

Thanks for addressing my comments.  One final reply on this thread:

On Thu, Jul 11, 2019 at 12:30:53PM +0000, Paolo Lucente wrote:
> Done. This opened a further consideration at my end. The document lacks a
> statement as in https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about
> “TLVs can be sent in any order.

While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
code point."  

Many implementations that deal with TLV based protocols will canonicalize
data structures based on the TLVs using sorted structures.  Having them
sorted on the wire means the canonicalization step is cheaper.

Note that this is a general justification for the procedure and it's not
critical for something like BMP.

>  Multiple TLVs of the same type can be
> repeated as part of the same message and it is left to the specific
> use-cases whether all, any, the first or the last TLV should be
> considered.”. In the specific case of VRF/Table Name one could have both a
> VRF id/name and a Table Name, hence the same TLV could be repeated twice
> (my take is that it’s a perfectly valid scenario). I’d tackle this case
> once i get green light from you that we are good about how your feedback
> was processed.

I suspect most vendors will eventually generate a composite name and send a
single TLV for the name.

It would not shock me at some point if this becomes sufficiently vendor
specific that we start seeing vendor specific TLVs here.

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Thu, 18 Jul 2019 16:21:56 +0000

Hi Jeff,

Thank you for your feedback. Inline my comments:

> On 18 Jul 2019, at 14:55, Jeffrey Haas <[email-masked]> wrote:
> 

Suggestion accepted, thank you, i will include it in the next edit. 

> specific that we start seeing vendor specific TLVs here.

Totally, i agree on your both points. My line of thought was: there are two main approaches for using the standard VRF/Table Name TLV: stacking values in a single TLV (what you mention) and breaking values in multiple TLVs. The former method is a given; i was simply thinking why not allowing also for the latter: while it increases flexibility “it does not seem to produce any harm” (tm).

Paolo

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 20 Jul 2019 00:52:27 +0000

Hi,

Regarding VRF/Table Name TLV:
Based on my understanding of RFC7854, I think the processing of VRF/Table Name TLV can be the same as Type 0 String TLV of BMP Initiation Message in RFC7854:
The VRF/Table Name TLV MAY be included multiple times.
If multiple strings are included, their ordering MUST be preserved when they are reported.

At the same time, this spec can also support processing multiple String Information into one composite String and then putting it into one TLV.

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Paolo Lucente
Sent: Friday, July 19, 2019 12:22 AM
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

Hi Jeff,

Thank you for your feedback. Inline my comments:

>> Done. This opened a further consideration at my end. The document 
>> lacks a statement as in 
>> https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about “TLVs can be sent in any order.
> 
> While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by 
> their code point."
> 
> Many implementations that deal with TLV based protocols will 
> canonicalize data structures based on the TLVs using sorted 
> structures.  Having them sorted on the wire means the canonicalization step is cheaper.
> 
> Note that this is a general justification for the procedure and it's 
> not critical for something like BMP.

>> Multiple TLVs of the same type can be repeated as part of the same 
>> message and it is left to the specific use-cases whether all, any, 
>> the first or the last TLV should be considered.”. In the specific 
>> case of VRF/Table Name one could have both a VRF id/name and a Table 
>> Name, hence the same TLV could be repeated twice (my take is that 
>> it’s a perfectly valid scenario). I’d tackle this case once i get 
>> green light from you that we are good about how your feedback was 
>> processed.
> 
> I suspect most vendors will eventually generate a composite name and 
> send a single TLV for the name.
> 
> It would not shock me at some point if this becomes sufficiently 
> vendor specific that we start seeing vendor specific TLVs here.

Paolo

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Paolo Lucente <[email-masked]>
Date: Sat, 20 Jul 2019 12:29:51 +0000

Hi Shunwan,

Thanks for your comments, inline:

> On 20 Jul 2019, at 02:52, Zhuangshunwan <[email-masked]> wrote:
> 

Thanks for the pointer.

> At the same time, this spec can also support processing multiple String Information into one composite String and then putting it into one TLV.

Totally, agree. It’s just probably not worth specifying it as part of the document.

Paolo