Re: [GROW] RFC7854 / RFC8671 BMP stats report for pre-policy / post-policy

[Tim Evens (tievens)]

Hi Yang,

There is lack of clarity with stat types as defined in 7854. It specifically 
called out Adj-RIB-In and defines non pre/post Adj-RIB-In stat types/metrics, 
such as Loc-RIB, duplicates, invalid by, etc.  This kind of renders the L flag 
misleading on some types considering some represent post processing metrics.  
8671 doesn’t attempt to redefine or correct 7854 in this sense.  Instead 8671 
calls out explicitly new types that should be used.  The O flag is specifically 
not set or ignored for stat reports, supporting backwards combability. Types 14 
– 17 if sent will be understood by the BMP receiver, as those are explicitly 
defined. L flag being set or not for types 14 – 17 is moot as the types clearly 
define the metric for the given peer defined by the per-peer header (sans L or 
O flags).

Thanks,
Tim

On 2/1/23, 6:23 PM, "GROW"  wrote:

Stats Reports follows per-peer header, which has L flag indicating
indicates that the message reflects post-policy

RFC7854 created stats type 7/8/9/10 for route counts, without
specifying whether they are pre or post policy

Later RFC8671 added stats report 14/15/16/17 with dedicated stat types
for pre / post policy in Adj-RIB-Out, making the route counter setup
inconsistent with Adj-RIB-In
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#statistics-types

Should L flag be meaningful for stats reports? If this is the case
data in type 7/8/9/10 would be expected to match L flag?
If not, why didn't stat type 7/8/9/10 get updated to match the setup
in RFC8671 for Adj-RIB-Out?

In JunOS 18's implementation, it appears stats reports are always sent
with L flag set to 0, even though only post-policy monitoring has been
configured.

a related discussion that predates RFC 8671
https://mailarchive.ietf.org/arch/msg/grow/Coqz738DPv7ZGVy-9GGzUBjtsF8/

Thanks.



Yang

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-09.txt

[Tim Evens (tievens)]

Comments inline.

On 10/13/22, 7:54 AM, "Paolo Lucente"  wrote:


Hi Tim,

Thanks for taking the time to review the draft, much appreciated. Some
comments inline:

On 13/10/22 01:41, Tim Evens (tievens) wrote:
> Hi Paolo, Yunan,
>
>  From section 1, intro:
>
> “This means that both Route Monitoring and Peer Down messages have a
> non-extensible format.”
>
> The above has been updated by section 5.3 RFC9069 where reason code 6
> includes TLVs.

Ack, i will refine text.

> “The proposal of this document is to bump the BMP version, for backward
> compatibility, and allow all message types to make provision for
> trailing TLV data.”
>
> Do all messages have to be version 4 for a session or can a BMP session
> use both versions based on the need for additional TLVs or not?

Good point, whichever direction it's good to add some text in this
sense. I would myself lean towards having a one unique protocol version.
So encode all messages as v4 if the implementation is compliant with
this draft.


[tevens] I agree for all messages in a TCP session be of the same version, but 
it does require that every message be set, such as init, peer up, peer down, … 
Little is being updated to support TLVs here, specifically in RM messages.  A 
version change will cause incompatibility with receivers for the entire stream 
of messages, including stats. If we do a version change, it might make sense to 
add more than TLVs. Let’s make it count.

> Some comments:
>
>   * The main use-cases call out route-monitor and peer down messages
> that didn’t have optional TLVs. RFC9069 updates Peer Down with
> reason code 6, that indicates TLVs to follow.  Might make sense to
> use that instead of changing it in version 4.

I find this a bit restrictive since reason code 6 calls only for TLV
data whereas other reason codes, ie. 1 and 3 do call also for the BGP
Notification PDU. I'd see this as complement to TLVs introduced with
code 6 and it would be indeed good for me to add some text / reference
about it.

[tevens] That would be good.  IMO, it would be good to reuse the existing IANA 
table TLVs that effect Peer Up/Down 
(https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#initiation-peer-up-tlvs).
 A new registry for other BMP message types makes sense… such as route-monitor 
TLVs.

>   * Instead of sorting TLVs by code point/type/… , wouldn’t it be okay
> to process them in order as they are encoded? In other words, let
> the sender define the order by how the sender encodes them. Having
> to sort would require buffering to process all TLVs so they can be
> sorted before processing/forwarding on.

It is a SHOULD so effectively you can do that without violating the
document. Would you have a preference to further relax it? The point
originally came from Jeff and what i like about it is that it implies
that if there are repetitions, they are batched together.

[tevens] Might be more clear to call out if it is the sender or receiver that 
is sorting. IMO, I prefer the sender to encode in the order the sender needs 
them to be processed by the receiver, regardless of type value ascending.  I 
don’t believe any of the TLVs require order processing by the receiver right 
now, but in the future that could change. The problem with sorting by type 
ascending value is that a new value added to the registry later may require it 
to be processed before a previous type… for example to support an override or 
influence how to process another TLV.

>   * To me, encoding per NLRI characteristics in TLVs with indexing is
> duplicate of attributes. It also could get large when a handful of
> NLRIs (sharing the same BGP attributes, packed into the same
> message) have different or shared BMP TLV characteristics.   For
> example, 10 NLRIs packed, 8 of them share characteristic A and the
> other 2 share characteristic B.  The TLV cannot be indexed as 0
> because all of them do not share the TLVs in common, resulting in 10
> TLVs being needed.

I see your point. I think we may have two main strategies here: take
care of this at packing time or propose a way to group NLRIs, in the
lack of better inspiration in this moment, a "Group TLV" with index 0
defining a new index to group a number of NLRIs. Would you have
(different) preferences, (different) proposal?


[tevens] A Group TLV would make sense, but it seems like that might be adding 
more complexity.  Hopefully folks wouldn’t use TLVs on route-monitor messages 
as a way to avoid or override path attributes.  I’m running into this now with 
ATTR_SET(128) 
https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/independent-domain-edit-routing-options.html.
 I’m updating OpenBMP to support multiple sets of path attributes.  Adding 
these TLVs could easily grow in

Re: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-09.txt

[Tim Evens (tievens)]

Hi Paolo, Yunan,

>From section 1, intro:
“This means that both Route Monitoring and Peer Down messages have a 
non-extensible format.”

The above has been updated by section 5.3 RFC9069 where reason code 6 includes 
TLVs.

“The proposal of this document is to bump the BMP version, for backward 
compatibility, and allow all message types to make provision for trailing TLV 
data.”

Do all messages have to be version 4 for a session or can a BMP session use 
both versions based on the need for additional TLVs or not?

Some comments:

  *   The main use-cases call out route-monitor and peer down messages that 
didn’t have optional TLVs. RFC9069 updates Peer Down with reason code 6, that 
indicates TLVs to follow.  Might make sense to use that instead of changing it 
in version 4.


  *   Instead of sorting TLVs by code point/type/… , wouldn’t it be okay to 
process them in order as they are encoded? In other words, let the sender 
define the order by how the sender encodes them. Having to sort would require 
buffering to process all TLVs so they can be sorted before 
processing/forwarding on.


  *   To me, encoding per NLRI characteristics in TLVs with indexing is 
duplicate of attributes. It also could get large when a handful of NLRIs 
(sharing the same BGP attributes, packed into the same message) have different 
or shared BMP TLV characteristics.   For example, 10 NLRIs packed, 8 of them 
share characteristic A and the other 2 share characteristic B.  The TLV cannot 
be indexed as 0 because all of them do not share the TLVs in common, resulting 
in 10 TLVs being needed.


  *   The current TLV types suggest the primary use case is per BMP message 
conveyance of BGP capabilities that effect how to parse the message itself.  
Such as add-paths, multiple labels, …  ASN encoding is already indicated by the 
“A” flag. Both RFC8277 and 3107 are the same in terms of decoding multiples of 
label 3 octets in length minus the prefix length. This can be handled stateless 
still.  RFC8277 does clarify what to expect in terms of number of labels, but 
from a stateless standpoint can’t we still process it as defined by 3107?  This 
draft focuses on stateless processing, where the Peer Up with the OPEN message 
was not seen and/or not considered.  I believe the only capability that is a 
problem is add-paths. Add-paths could be handled with a new flag. I believe all 
the other BGP TLVs are defined well enough to process the message without 
having to see the OPEN message exchange. Are there others that cannot be 
processed stateless?



  *   A VRF name is conveyed via Peer Up and Peer Down and not included in each 
route-monitor message.  Strictly stateless, the receiver would not know which 
VRF name the per-peer header correlates to without having some level of state 
correlation of per-peer header values to Peer Up/Down. Maybe for VRF name it 
doesn’t matter, but at some point receivers are expected to keep some level of 
state for peering sessions. This is needed with RIB state tracking and 
route-refreshes, which may come in via route-mirror message or another/repeated 
Peer Up message, but not in the form of a route-monitor message.


Thanks,
Tim





On 10/12/22, 5:34 AM, "GROW"  wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : TLV support for BMP Route Monitoring and Peer Down 
Messages
Authors : Paolo Lucente
  Yunan Gu
  Filename: draft-ietf-grow-bmp-tlv-09.txt
  Pages   : 7
  Date: 2022-10-12

Abstract:
   Most of the message types defined by the BGP Monitoring Protocol
   (BMP) make provision for optional trailing data.  However, Route
   Monitoring messages (which provide a snapshot of the monitored
   Routing Information Base) and Peer Down messages (which indicate that
   a peering session was terminated) do not.  Supporting optional data
   in TLV format across all BMP message types allows for a homogeneous
   and extensible surface that would be useful for the most different
   use-cases that need to convey additional data to a BMP station.
   While it is not intended for this document to cover any specific
   utilization scenario, it defines a simple way to support optional TLV
   data in all message types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-tlv-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW 

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

When I wrote route-refresh, that was from the router/sender side, not BMP 
receiver sending a route-refresh. BMP is still write-only.

There are use-cases for re-syncing the RIB to the BMP receiver.  Some of the 
methods today are to clear the peer, request a route-refresh in, or to reset 
the BMP feed. This is a bit intrusive to the router (sender) and BMP receiver. 
Having to go to the router to request a refresh to the BMP server, IMO, is 
still okay.  The problem is that control knobs for refresh are at the BGP peer 
level, not BMP.  For Adj-RIB-In Pre-Policy, it makes sense to do that on the 
peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn’t really make 
sense.  Having a knob to initiate BMP side refresh would be very nice and 
hopefully less intrusive.

Regardless of the BMP server needing a refresh, a BMP server does not know when 
someone has requested route-refresh IN at the peer level (maybe it was 
requested for policy change, …) Instead, the BMP receiver, blindly, receives a 
boat load of updates with no awareness that it was a new RIB dump or controlled 
refresh. In this case, it would appear to be churn.  IMO, there is value in 
having a message to signal the receiver that a refresh is coming, followed by 
an EoR.  A PEER_UP could be used for this, but that is intrusive and misuse of 
PEER_UP.

--Tim

On 9/22/22, 11:03 AM, "Jeffrey Haas"  wrote:



> On Sep 21, 2022, at 7:42 AM, Zhuangshunwan 
>  wrote:
>
> Hi Tim and All,
>
> I think the idea of a "BMP route refresh" would be appreciated,  it will 
> helps keep the information synchronized between the BMP Server and the BMP 
> Client.

Would someone clarify what they mean by a bmp route refresh?

The BMP protocol was intentionally designed as write-only.

-- Jeff
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

>> “Also, I had thought the RFC was reasonably clear on this point:“

That’s under route monitoring. Time is part of the common header.

Timestamp: The time when the encapsulated routes were received
  (one may also think of this as the time when they were installed
  in the Adj-RIB-In), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

Problem is that the RFC didn’t really clarify the other messages well for time. 
 If the sender is going to send timestamps based on received updates, then it 
MUST honor that for all messages, such as PEER_UP, PEER_DOWN, route mirroning, 
etc.

State-compression is effected by BMP header timestamp with packed NRLIs. They 
will need to be broken out due to timestamp of when last changed.

Not all BMP senders are not respecting the statement about “received time” and 
instead are sending timestamps based on the BMP send time of the message.

The other problem that we are running into is the BMP sender clock is not in 
sync with the BMP receivers.  Either it’s a different clock source or something 
else.  Regardless, it causes things to be out of sync, especially when 
monitoring BGP churn/excessive updates/bad neighbors/etc.   Might be good to 
clarify a bit more that the time transmitted in BMP header shouldn’t really be 
used for churn/update floods/… Instead, BMP receiver should be expected to add 
a timestamp that can be used for that.

--Tim



On 9/22/22, 11:19 AM, "GROW"  wrote:



> On Sep 21, 2022, at 10:29 AM, Maximilian Wilhelm  wrote:
>
> Hey folks,
>
> I think having the original timestamp of when a route was learned is
> valueable, even if theP BM session is set up later, or has flapped and
> is reestablished etc.  This was it's always possible to determine when
> a given prefix/path was learned.  If you want to have the time the
> informatione was learned via BMP it's also possible to use the current
> time then to store it into a TSDB.  So following the principle of always
> keeping the most options I think we should make sure the timestamp always
> represents the one where the BGP UPDATE happened.  As most (if not all?)
> routers already store that time / a route age, that information should
> already be available.

Also, I had thought the RFC was reasonably clear on this point:

   If the implementation is able to provide information about when
   routes were received, it MAY provide such information in the BMP
   Timestamp field.  Otherwise, the BMP Timestamp field MUST be set to
   0, indicating that time is not available.

"when routes were received".

But it's also clear about the MAY.

Time highlights below that part of the issue is that with the level of 
flexibility the field provides that it can make data from different routers 
incomparable.

> Anno domini 2022 Tim Evens (tievens) scripsit:
>
>> Timestamp is another item we need to clarify in 7854bis. Some BMP senders 
>> send timestamps based on the actual received BGP update.  This may be days, 
>> weeks, etc. old from the time that the message is sent to BMP receiver. It 
>> has been a bit confusing for people to see timestamps that are old when they 
>> just received a RIB dump.

The field in BMP is for the BGP time carried in the BMP protocol.  The state 
described above is meta-data about a BMP receiver having received a given BGP 
route.

>> OpenBMP/PSQL maintains two timestamps, one is the DB insert time and the 
>> other is the BMP received timestamp.  For folks that are working with time 
>> series DBs to track/insert/maintain records using time, they may drop 
>> messages because they believe they are too old when in fact they are new.   
>> Basically, for those that are using timeseries DBs, they may have to use a 
>> new BMP received timestamp instead of the BMP header timestamp.

For timeseries purposes, it depends on what you're doing timeseries upon.

If you're looking for route stability, the freshness of your BMP message is 
less interesting than the sending router's timestamp for when it got the route.

If you're looking for churn at an arbitrary epoch after you've synched your 
feeds, then the BMP message receive time may be preferable.

That said, given that the timestamps carried in BMP aren't guaranteed to mean 
the same things from implementation to implementation, normalizing the time can 
be a challenge.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

Totally agree that the original is important, but there are several BGP senders 
that do not send the original timestamp.  How do we know if it’s original or 
the time when the router/sender sent the BMP message? Right now, we know only 
based on known implementations that honor the original vs others that do not.  
RFC7854 defines both sender and receiver. The timestamp issue with TSDB is more 
on the receiver side.  The receiver should likely add a timestamp if using 
TSDB. This would allow the original to still be recorded but have a current 
timestamp as well. This is exactly what OpenBMP does and I’m sure other 
receivers are doing the same by now.

BTW, there is at least one software based BGP stack that sends BMP messages 
with ZERO value for time. I’ve had to update OpenBMP collector to specifically 
add a timestamp when this happens.

Thanks,
Tim

On 9/21/22, 7:29 AM, "GROW"  wrote:

Hey folks,

I think having the original timestamp of when a route was learned is
valueable, even if theP BM session is set up later, or has flapped and
is reestablished etc.  This was it's always possible to determine when
a given prefix/path was learned.  If you want to have the time the
informatione was learned via BMP it's also possible to use the current
time then to store it into a TSDB.  So following the principle of always
keeping the most options I think we should make sure the timestamp always
represents the one where the BGP UPDATE happened.  As most (if not all?)
routers already store that time / a route age, that information should
already be available.

Cheers,
Max

Anno domini 2022 Tim Evens (tievens) scripsit:

> Timestamp is another item we need to clarify in 7854bis. Some BMP senders 
> send timestamps based on the actual received BGP update.  This may be days, 
> weeks, etc. old from the time that the message is sent to BMP receiver. It 
> has been a bit confusing for people to see timestamps that are old when they 
> just received a RIB dump. OpenBMP/PSQL maintains two timestamps, one is the 
> DB insert time and the other is the BMP received timestamp.  For folks that 
> are working with time series DBs to track/insert/maintain records using time, 
> they may drop messages because they believe they are too old when in fact 
> they are new.   Basically, for those that are using timeseries DBs, they may 
> have to use a new BMP received timestamp instead of the BMP header timestamp.
>
> Thanks,
> Tim
>
> On 9/21/22, 6:44 AM, "GROW"  wrote:
>
> Hi Robert,
>
> Yes, but only for the RIB dump (on initial PEER_UP and for each 
> route-refresh) till EoR.  Senders shouldn’t state compress after that, 
> especially for Adj-RIB-In Pre-Policy.  State compression should be optional. 
> State compression is not required for the RIB dump or at any time, but it 
> does help deal with churn while the RIB dump is in progress.
>
> Thanks,
> Tim
>
> On 9/20/22, 10:52 PM, "Robert Raszuk"  wrote:
>
> Hi Paolo,
>
> A-la: there is multiple updates related to a certain NLRI by when a BMP
> message is to be sent out, let's state-compress (ie. not send out) those
> that were already obsoleted by a subsequent update.
>
> But this will hide BGP churn for a given NET to be detectable by BMP 
> receiver. Is this a good thing ? I am not sure. It is a loss of information 
> to me.
>
> Thx,
> R.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

Timestamp is another item we need to clarify in 7854bis. Some BMP senders send 
timestamps based on the actual received BGP update.  This may be days, weeks, 
etc. old from the time that the message is sent to BMP receiver. It has been a 
bit confusing for people to see timestamps that are old when they just received 
a RIB dump. OpenBMP/PSQL maintains two timestamps, one is the DB insert time 
and the other is the BMP received timestamp.  For folks that are working with 
time series DBs to track/insert/maintain records using time, they may drop 
messages because they believe they are too old when in fact they are new.   
Basically, for those that are using timeseries DBs, they may have to use a new 
BMP received timestamp instead of the BMP header timestamp.

Thanks,
Tim

On 9/21/22, 6:44 AM, "GROW"  wrote:

Hi Robert,

Yes, but only for the RIB dump (on initial PEER_UP and for each route-refresh) 
till EoR.  Senders shouldn’t state compress after that, especially for 
Adj-RIB-In Pre-Policy.  State compression should be optional. State compression 
is not required for the RIB dump or at any time, but it does help deal with 
churn while the RIB dump is in progress.

Thanks,
Tim

On 9/20/22, 10:52 PM, "Robert Raszuk"  wrote:

Hi Paolo,

A-la: there is multiple updates related to a certain NLRI by when a BMP
message is to be sent out, let's state-compress (ie. not send out) those
that were already obsoleted by a subsequent update.

But this will hide BGP churn for a given NET to be detectable by BMP receiver. 
Is this a good thing ? I am not sure. It is a loss of information to me.

Thx,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

Hi Robert,

Yes, but only for the RIB dump (on initial PEER_UP and for each route-refresh) 
till EoR.  Senders shouldn’t state compress after that, especially for 
Adj-RIB-In Pre-Policy.  State compression should be optional. State compression 
is not required for the RIB dump or at any time, but it does help deal with 
churn while the RIB dump is in progress.

Thanks,
Tim

On 9/20/22, 10:52 PM, "Robert Raszuk"  wrote:

Hi Paolo,

A-la: there is multiple updates related to a certain NLRI by when a BMP
message is to be sent out, let's state-compress (ie. not send out) those
that were already obsoleted by a subsequent update.

But this will hide BGP churn for a given NET to be detectable by BMP receiver. 
Is this a good thing ? I am not sure. It is a loss of information to me.

Thx,
R.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

Inline, marked 

On 9/19/22, 3:10 PM, "Robert Raszuk"  wrote:

Hi Tim,


· What does the sender do with the live updates that are happening 
while the RIB dump is taking place, should they queue/buffer and flood after 
RIB dump or drop them? IMO, dropping them is not an option. Ideally the sender 
should queue those and then send them (e.g., replay) them after the RIB dump 
(after sending the EoR).  Basically append them to the end of queue for 
transmission to the BMP receiver. State-compression could be used here to 
reduce the queue after RIB-DUMP.  We’ll likely need to discuss this a bit more…


BGP RIB dump is just a full BGP table being sent to a peer (regular peer or BMP 
peer). The main BGP RIB table does not freeze during such an event. It is still 
live - for BGP it is business as usual.


So when new updates come in during sending they are added to the BGP table, 
best path is run etc ... If the prefix sent to the receiver was not yet sent it 
will be propagated with new info.  If it was already sent the new update will 
be generated and sent after initial dump as simple BGP increment. It could be 
UPDATE MSG or WITHDRAW depending on the actual info which arrived during the 
cycle.

 The above works with a per flow/session based transmission, as in BGP 
peering sessions. This would work well if BMP senders implemented a per peer 
buffer where messages were either delayed or enqueued in FIFO order per peer.  
Basically start RIB dump, keep track of where you are sending the RIB and 
enqueue updates to the tail end.   NOTE, state compression can be performed for 
pending updates to BMP, but for pre-policy but it does not involve best-path.

The challenge comes with the BMP buffer/queue via the TCP connection and how 
the sender handles sending a RIB dump while changes are happening real-time. 
For example, 100’s of peers need to be RIB dumped, the sender starts in 
parallel (threaded) to send the first 10 peers, then it progressively moves on 
to other peers 10 at a time. RIB dump is delayed by the BMP buffer/TCP 
connection.  If peer 1 RIB dump NLRI 1.1.1.0/24 has been sent/enqueued with 
state A, this is transmitted, but while the RIB dump is in progress, state of 
1.1.1.0/24 has changed. It’ll have to wait till after the RIB dump, or does it? 
 Do you add it to the live stream of the RIB DUMP still in progress or do you 
wait till after the initial RIB DUMP with an EoR? Obviously if a prefix, such 
as 8.8.8.0/24 that has yet to be enqueued can benefit from state compress 
before enqueuing.  Although, that’s not written.



Note that in some implementations all of the above may be multithreaded and 
happening in parallel. That is why there are flags in BGP RIB to assist with 
per peer deltas or per peer BGP tables like Adj-RIB-out.

Thx,
R.






On Mon, Sep 19, 2022 at 10:42 PM Tim Evens (tievens) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Let’s make sure to address that the bis is more than just an EoR update…

@John Scudder<mailto:jgs=40juniper@dmarc.ietf.org>, @Paolo 
Lucente<mailto:pa...@ntt.net> and I discussed back in 2017 several updates to 
fix/clarify 7854 in terms of implementations of senders and receivers…  It was 
on the table to create a new RFC instead of a bis to go over sender and 
receiver implementations.

Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069 (Local-RIB).   
RFC9069 defines a new peer type and makes it very clear to the receiver that 
the messages are for Local-RIB. RFC8671 follows RFC7854, but clarifies that 
PEER_(UP|DOWN) are singular to the route-(mirroring | monitor) messages.  In 
other words, for Local-RIB we know which messages are Local-RIB by peer type, 
but for Adj-RIB-Out and Adj-RIB-In (both pre and post policy) we have to look 
at flags (per mirroring/monitor message) and distinguish.

Correlating NLRIs (BGP updates) to PEER state (peer-(up|down) and capabilities 
advertised) works when we can hash/identify per-peer header to PEER_(UP|DOWN) 
per-peer headers.  If they equal, then they are associated.

When working with anything other than RFC9069, you send a SINGLE 
PEER-(UP|DOWN). The route-(mirroring/monitor) messages are then 
linked/associated by peer type. AFI/SAFI (rib-out, rib-in, pre-policy, 
post-policy) are NLRI level.  OpenBMP, as an example, will hash based on this.  
It expects a single PEER-(UP|DOWN) that is re-used for the other AFI/SAFIs and 
tables (in, out) and mix of pre vs post policy.   The only exception to this is 
Local-RIB, which is very clear on the usage. The problem I see is that this is 
not clearly articulated in RFC7854 or RFC8671…. Although 8671 inherits 7854, so 
a BIS for 7854 will address 8671.

OpenBMP takes the approach of hashing NLRI (bgp updates) and peer up/down 
messages to associate them together. When we receive a PEER DOWN, we mark NLRIs 
associated as withdrawn.   Upon PEER UP, we delete and rebuild the RIB. This is 
where EoR is very important

Re: [GROW] [Idr] RFC7854: EoR

[Tim Evens (tievens)]

Let’s make sure to address that the bis is more than just an EoR update…

@John Scudder, @Paolo 
Lucente and I discussed back in 2017 several updates to 
fix/clarify 7854 in terms of implementations of senders and receivers…  It was 
on the table to create a new RFC instead of a bis to go over sender and 
receiver implementations.

Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069 (Local-RIB).   
RFC9069 defines a new peer type and makes it very clear to the receiver that 
the messages are for Local-RIB. RFC8671 follows RFC7854, but clarifies that 
PEER_(UP|DOWN) are singular to the route-(mirroring | monitor) messages.  In 
other words, for Local-RIB we know which messages are Local-RIB by peer type, 
but for Adj-RIB-Out and Adj-RIB-In (both pre and post policy) we have to look 
at flags (per mirroring/monitor message) and distinguish.

Correlating NLRIs (BGP updates) to PEER state (peer-(up|down) and capabilities 
advertised) works when we can hash/identify per-peer header to PEER_(UP|DOWN) 
per-peer headers.  If they equal, then they are associated.

When working with anything other than RFC9069, you send a SINGLE 
PEER-(UP|DOWN). The route-(mirroring/monitor) messages are then 
linked/associated by peer type. AFI/SAFI (rib-out, rib-in, pre-policy, 
post-policy) are NLRI level.  OpenBMP, as an example, will hash based on this.  
It expects a single PEER-(UP|DOWN) that is re-used for the other AFI/SAFIs and 
tables (in, out) and mix of pre vs post policy.   The only exception to this is 
Local-RIB, which is very clear on the usage. The problem I see is that this is 
not clearly articulated in RFC7854 or RFC8671…. Although 8671 inherits 7854, so 
a BIS for 7854 will address 8671.

OpenBMP takes the approach of hashing NLRI (bgp updates) and peer up/down 
messages to associate them together. When we receive a PEER DOWN, we mark NLRIs 
associated as withdrawn.   Upon PEER UP, we delete and rebuild the RIB. This is 
where EoR is very important!!!

The problem I see today is that senders (Cisco, Juniper, Huawei, Arista, …) are 
unclear based on RFC7854 if they:



  *   should send multiple PEER_(UP|DOWN) messages based on flags (rib-out, 
rib-in, pre-policy, post-policy)
  *   EoR should be per AFI/SAFI (IMO this should be an obvious yes)
  *   Route-Refresh; 7854 doesn’t call this out, but should I send a 
ROUTE-REFRESH message to BMP receiver or not?? IMO, YES… send it and we’ll 
trigger a delete/purge and rebuild based on it. EoR will be expected.
  *   What does the sender do with the live updates that are happening while 
the RIB dump is taking place, should they queue/buffer and flood after RIB dump 
or drop them? IMO, dropping them is not an option. Ideally the sender should 
queue those and then send them (e.g., replay) them after the RIB dump (after 
sending the EoR).  Basically append them to the end of queue for transmission 
to the BMP receiver. State-compression could be used here to reduce the queue 
after RIB-DUMP.  We’ll likely need to discuss this a bit more…


Thanks,
Tim

On 9/16/22, 3:17 AM, "GROW"  wrote:

Hi all,

Vincent, thanks for bringing this up. We've been puzzled about what to
expect exactly, too.

On Thu 15 Sep 2022, 01:08, Maximilian Wilhelm wrote:
> Anno domini 2022 Jeffrey Haas scripsit:
>
> > (..) the per-AFI/SAFI end of rib is a feature rather than a bug.
> >
>
> I fully agree with that. Having one marker per AF seems to be the much
> better option as it clearly indicates which RIB is fully transmitted/
> recieved/mirrored and also feels simpler to implement in a safe and
> sane way.
>
> (..)
>
> So I'd say lets stay with EoR and clarify it's to be send per AF and
> we should be in a better place.

I agree we should keep the EoRs, and we should not aim for a single
'Done'-message or drop this feature altogether. In addition to having a
EoR per AFI/SAFI, I think there are implementations that distinguish
pre- vs post-policy as well, i.e. sending out two EoRs per AFI/SAFI.

It might be good to clarify the text regarding that exact behavior too.
Are EoRs per pre/post policy useful? As a BMP consumer, I'm in favour.

Related question: should an implementation send out an EoR for empty
tables, i.e. a combination of {AFI/SAFI/policy} for which no actual
routes are stored and thus nothing is sent from the router to the BMP
monitoring station? Could/should one expect an EoR for such a
combination without having received any RouteMonitoring messages for
that combination?
And with BMP for Loc-RIB and Adj-RIB-Out, I guess similar questions
apply, and we actually have to reason about combinations of
{RIB/AFI/SAFI/policy} ?


Thanks,
 luuk

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang

[Tim Evens (tievens)]

   // Connection, missing tcp tuning params
   // like keep-alives, segment sizes, etc.

TCP keep-alives SHOULD be enabled by default if possible. The ability to tune 
them is also important.  Window sizes have been a challenge over higher latency 
BMP sessions. We should be able to adjust/configure scaling/etc.

In addition to TCP tuning, I do like the ability to configure an initiation 
delay as well as backoff timers.  If the BMP session is flapping, then at some 
point it should backoff and wait a little longer.

Thanks,
Tim


On 3/7/22, 2:08 AM, "GROW"  wrote:

Hi Grow,

We just submitted a new draft proposing a yang module for configuring and 
managing BMP on a device.

It would be nice to get some comments, observations, etc.

Grow Chairs, will it be possible to get a 5 minute slot in the next session to 
give an overview of this module?

Thanks,
Camilo Cardona



>
> On 7/3/22, 10:51, "internet-dra...@ietf.org"  
> wrote:
>
>
>A new version of I-D, draft-cptb-grow-bmp-yang-01.txt
>has been successfully submitted by Camilo Cardona and posted to the
>IETF repository.
>
>Name:  draft-cptb-grow-bmp-yang
>Revision:  01
>Title: BMP YANG Module
>Document date: 2022-03-07
>Group: Individual Submission
>Pages: 14
>URL:
> https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt
>Status: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/
>Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang
>Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01
>
>Abstract:
>   This document proposes a YANG module for BMP (BGP Monitoring
>   Protocol) configuration and monitoring.  A complementary RPC triggers
>   a refresh of the session of a BMP station.
>
>
>
>
>The IETF Secretariat
>
>
>
>

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] draft-ietf-grow-bmp-local-rib-11 Peer Flags IANA Conflict Resolution

[Tim Evens (tievens)]

There is a conflict between the IANA registry 
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags 
and https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-10#section-4.2.  
Originally, we defined that flag 0 would indicate the F flag but IANA put this 
as flag 4 under the existing peer flags registry.

Does anyone know if any implementation exists today expecting flag 0? If so, is 
it a significant problem if we changed it to flag 4 to be consistent with IANA 
draft assignment?  We are still requesting a new registry "BMP Peer Flags for 
Loc-RIB Instance Peer Type 3."   This registry will start off with flag 4 being 
assigned as the F flag.  
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-11#section-8.2 
describes this request.


Thanks,
Tim
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

[Tim Evens (tievens)]

I'm new to the process.  When is the discussion scheduled?  I believe there is 
a telechat on 4/8 at 7am PDT.  Is this when you want to discuss this?  I have 
not seen an invite with a link for the conference/meeting.

I have lc, rtgdir, and secdir updates in revision 11 that have not been 
submitted yet (https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib).   The 
below would require some minor updates.  I can add those to the pending updates 
to revision 11.  All the updates are minor/clarifications so far.  AFAIK, the 
issue with IANA peer flags and title update of "Initiation … TLVs" have been 
resolved.

I'll send a respond to the below nits and peer flag question tomorrow, PDT time.

Thanks,
Tim

On 4/5/21, 12:43 PM, "Alvaro Retana via Datatracker"  wrote:


Alvaro Retana has entered the following ballot position for
draft-ietf-grow-bmp-local-rib-10: Discuss

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-grow-bmp-local-rib/



--
DISCUSS:
--

I am balloting DISCUSS because there are significant clarity issues.

(1) 4.2.  Peer Flags

   In section 4.2 of [RFC7854], the "locally sourced routes" comment
   under the L flag description is removed.  If locally sourced routes
   are communicated using BMP, they MUST be conveyed using the Loc-RIB
   instance peer type.

This change is bigger than simply removing a comment: it is changing the
behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the same
considerations apply?   I would like to see a clearer treatment of the change
related to locally sourced routes -- a separate section/sub-section seems
appropriate.

(2) §4.2/8.2: Peer Flags

§4.2 defines a new Flag as follows:

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |F|  Reserved   |
 +-+-+-+-+-+-+-+-+

But it doesn't mention that this field is intended to be specific to the
Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:

   This document defines a new flag (Section 4.2) and proposes that peer
   flags are specific to the peer type:

The registry [1] shows that the early allocation was made in the "generic" (not
per-peer-type) Peer Flags field.  The flags defined in rfc7854 and rfc8671 both
assume the same set of Flags for all peer types.

[1]
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags

(3) §5.4 (Route Monitoring)  The implication in this section is that a BGP
UPDATE includes the route information -- but the information in the Loc-RIB may
not have come from BGP, so there is no BGP UPDATE to propagate.  This clearly
is a case where the UPDATE is fabricated.  Please provide specific instructions
on how this UPDATE is constructed, including any path attributes.


--
COMMENT:
--

(1) §3 (Definitions)

   *  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
  an Adj-RIB-Out. This MUST be what is actually sent to the peer.

s/This MUST be what is actually sent to the peer./This is what is sent to the
peer.

Note that this document should not use Normative language related to what a BGP
session does.  In this case, that is rfc4271's job.

(2) §5.2 (Peer UP Notification): "Capabilities MUST include the 4-octet ASN and
all necessary capabilities to represent the Loc-RIB route monitoring messages.
Only include capabilities if they will be used for Loc-RIB monitoring messages."

Which are the capabilities that "will be used for Loc-RIB monitoring messages"?
 The action above is required (MUST), but no specifics are given.

(3) §5.2.1: "The Information field contains a UTF-8 string whose value MUST be
equal to the value of the VRF or table name (e.g.  RD instance name) being
conveyed."

- Please take a look at the Shutdown Communication string definition in rfc9003
and use a similar definition.

- The "value of the VRF or table name" is a local matter, right?  How can the
requirement be normatively enforced?  How can the receiver enforce the "MUST"?
IOW, s/MUST.../The information field contains the value of the VRF or table
name...

- There's no need to redefine the TLV in §5.3.

(4) §5.4: "As defined in section 4.3 of [RFC7854]..."  The quote comes from
§4.6.

(5) §5.5 (Route Mirroring): "Route mirroring is not applicable to Loc-RIB and
Route Mirroring messages SHOULD be ignored." 

Re: [GROW] Secdir last call review of draft-ietf-grow-bmp-local-rib-10

[Tim Evens (tievens)]

Thank you so much for your review.  I have updated the doc per your suggestions.

"  The same considerations as in section 11 of [RFC7854] apply to this
   document.  Implementations of this protocol SHOULD require monitored
   routers to establish secure sessions with authorized and trusted
   monitoring stations.  It is also believed that this document does not
   add any features that require any additional security considerations."


On 3/29/21, 3:51 PM, "Chris Lonvick via Datatracker"  wrote:


Reviewer: Chris Lonvick
Review result: Has Nits

Hello,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is READY.

The authors state in the Security Considerations section that the same
considerations that are documented in Section 11 of RFC 7854 also apply to this
document. I see no reason to doubt that and I believe that is appropriate for
this document.

The second and third sentences of the Security Considerations section may need
to be reworked. Although I skimmed the rest of the document, these were the
only nits I could see.

For the second sentence, rather than:
Implementations of this protocol SHOULD require to establish sessions with
authorized and trusted monitoring devices. Perhaps, Implementations of this
protocol SHOULD require  +monitored routers+  to establish  +secure+  sessions
with authorized and trusted monitoring  -devices-+stations+. The term
"monitoring devices" is not used anywhere else in the document, and only once
in RFC 7854. On the other hand "monitoring stations" is used extensively in
both.

For the third sentence, rather than:
It is also believed that this document does not add any additional security
considerations. Perhaps, It is also believed that this document does not add
any  +features that require any+  additional security considerations.

Best regards,
Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bmp-local-rib-10

[Tim Evens (tievens)]

Hi Thomas,

Thank you for your review and catching these nits.  Please see my comments 
marked [tievens] inline.
You can see my pending PR 
(https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/22) for all these 
changes.  Once approved, I'll submit revision 11.


On 3/20/21, 3:33 AM, "Thomas Fossati via Datatracker"  wrote:


Reviewer: Thomas Fossati
Review result: Ready with Issues

Nits:

* Figure 1:
  * a couple of '+' are missing in the top-right and bottom-right
corners of the Adj-RIB-In (Post) box;

[tievens] Updated.

* "e.g." => "e.g.," in multiple places;
[tievens] Updated.


* A few acronyms are not expanded:
* IGP, BGP-LS, SPF, CSPF. VRF, ASN, BGP-ID, RD (route
  distinguisher?)


[tievens] I've updated these abbreviations following 
https://tools.ietf.org/html/rfc7322#section-3.6.

I suppose the statement  "The exception is an abbreviation that is so common 
that the readership of RFCs can be
   expected to recognize it immediately" is a bit subjective.


* Section 1.1
* "directly effects" => "directly affects"

[tievens] Updated.

* Section 3
  * "an instance of an instance of BGP-4" => "an instance of BGP-4"
[tievens] Updated.

* Section 5
  * "post-policy" => "Post-Policy"
  * "ie." => "i.e.,"

[tievens] Updated.

* Section 5.1
  * "in The Loc-RIB, expressed" => "in the Loc-RIB, expressed"

[tievens] Updated.

* Section 5.2.1
  * Consider using "Peer Up" instead of "Peer UP" for consistency with
the capitalisation use in RFC7854 (also in Sections 5.3, 5.4.1, 6.1,
6.1.1, 6.1.3, and 8.3)

[tievens] Updated to Peer Up.


* Section 5.3
  * "peer Down" => "Peer Down"

[tievens] Updated.

* Section 6.1
  * "local router emulated peer." maybe "locally emulated peer."

[tievens] Updated.

* Section 6.1.1
  * "since it represents the same Loc-RIB instance" => "since they
represents the same Loc-RIB instance"

[tievens] Updated.

Editorial improvements:

* Section 1.1
* I had some troubles parsing: "Complexities introduced by the lack
  of access to Loc-RIB in order to derive (e.g. correlate) peer to
  router Loc-RIB:", in particular the bit "in order to derive (e.g.
  correlate)".  Is it "in order to derive (i.e., correlate)" or "in
  order to derive (or correlate)" or "in order to correlate"?

[tievens] How about changing it to: "Complexities introduced when correlating a 
received Adj-RIB-In as a router Loc-RIB:"

* What does "suppresses more specifics" mean?  Is there a term
  missing?
[tievens] I've updated it to: "more specific prefixes"

* What does "derive a Loc-RIB to a router" mean? Is it "derive the
  Loc-RIB of a router" instead?
[tievens] Yes. Updated.

* I find this "The BGP-IDs and session addresses to router
  correlation requires additional data" a bit hard to parse. Maybe
  re-flow it as: "Correlating BGP-IDs and session addresses to a
  router requires additional data"

[tievens]  Updated to use your re-flow…

* Section 4.1
  * I find "to distinguish that it represents Loc-RIB with or without RD
and local instances" a bit hard to parse.  I suggest rephrasing it
to make it clearer.

[tievens]  Changed to: "A new peer type is defined for Loc-RIB to distinguish 
that it represents the router Loc-RIB, which may have a route distinguisher 
(RD)."

* Section 5
  * Re: setting the F flag.  It'd help if you put a forward ref to
Section 6.1.2 here.  (Before getting to 6.1.2 I got baffled by F; in
particular, it was not clear to me from the surrounding text what is
the monitoring station supposed to do with partial information
without knowing exactly how much and what kind of info has been
left out.)

[tievens] Updated. Slight rewording: "As described in Section 6.1.2, a subset 
of Loc-RIB routes MAY be sent to a BMP collector by setting the F flag."

* Section 5.2
  * Should add-paths be ADD-PATH instead?  If so, maybe you could also
add an informative reference to RFC7911

[tievens] Updated to ADD-PATH with reference.

  * In "The duplication allows the BMP receiver to use existing parsing"
could you clarify what "existing parsing" mean?

[tievens] Updated to: "Repeat of the same Sent Open Message.  The duplication 
allows the BMP receiver to parse the expected received OPEN message as defined 
in section 4.10 of [RFC7854]."

* Section 5.5
  * Why would the receiver decide not to ignore a Route Mirror message?
And what would happen if it decided so?  I'm asking because I don't
understand the reasons for a SHOULD rather than a MUST here.

[tievens] Updated to clarify.  "Section 4.7 of [RFC7854] defines Route 
Mirroring for verbatim duplication of messages received.  This is not 
applicable to Loc-RIB considering PDUs are originated by the router.  Any 
received Route Mirroring messages SHOULD be ignored."
* Section 6.1.1
  * In "There MUST be multiple emulated peers for each Loc-RIB instance"
I am unsure whether what you want to say is that "there MUST be 

Re: [GROW] is TCP the right layer for BMP session resumption?

[Tim Evens (tievens)]

The use of UDP vs TCP is use-case specific.  For example, are you logging and 
don't care if you miss messages or are you maintaining RIB states for 
applications like SDN?   

In terms of accurate logging (ordered regardless of timestamp) and maintaining 
state… TCP is required otherwise we introduce out-of-order and loss recovery 
complexities.  BGP PDU order is required in order to track changes and to 
maintain accurate RIB states.   While a SEQ number in BMP can help to 
re-sequence messages, that puts a lot on every BMP receiver/client. For 
example, BMP receivers will now have to buffer messages and re-sequence them to 
ensure proper ordering when processing.   If buffers are exceeded, what happens 
to those messages and how would the BMP receiver request those missing 
messages/pdus?  Regardless of how, this adds complexity to both the sender and 
receiver.  IMO, this is not addressing the problem of RIB dumps or picking up 
where you left off on reconnect.  

The draft suggests to use TCP_FAST_OPEN, which I believe adds more complexity 
while not solving the other challenges relating to RIB dumps/refreshes.   It 
doesn't address PEER UP handling on reconnect, how to handle peers that change 
or are new during the no-connection time,  and on how to request a peer refresh 
when needed.   It also doesn't address the buffer exhaustion problem on the 
sender (router) side.  IMO, the sender should be configured using buffer sizes 
per receiver and not based on time.   The amount of time is relative to the 
number of updates.  For example, a refresh to update policies will 
flood/exhaust buffers quickly in seconds while normal updates may last for 
minutes without buffer exhaustion.   

There are at least three problems with RIB dumps/reconnects to be solved:

1) Transient reconnects due to network failures, restarts of receivers, etc. 
are resulting in unnecessary INITs, RIB dumps, and PEER UPs.  A PEER UP 
normally means that the receiver invalidates all previous RIB entries as it 
does not know if things were changed/removed during the gap (from last PEER 
UP/DOWN) period.  A RIB dump is expected to refresh the peer RIB upon a PEER 
UP.  IMO, what we need is application level control so the BMP receiver can 
send a control message to the sender to indicate what's needed per-peer.  For 
example, a receiver restart (new connection) may require a full refresh of PEER 
UPs and RIB dumps, partial refresh on a subset of peers, only new peers since 
last reconnect time, and/or no refresh at all for any of the given peers.  
Unless a refresh/RIB dump is requested or needed, messages should continue 
where they left off based on buffer allocations (e.g., offsets or similar).  
IMO, the fast reconnect does not address the set of peers, especially 
considering the peers that changed during the no-connect period. 


2) Regardless of quick restarts or transient network problems, sometimes a RIB 
dump and PEER UP is not needed.  It would be nice to pick up where we left off, 
if that is possible.  This should be per-peer instead of being binary at the 
session level due chatty peers causing an issue with buffering. This can 
include use-cases for logging, where the logging process does not actually care 
for a RIB dump at all.  Instead, it only wants new messages starting at BMP 
receiver connect time (based on peer and afi/safi).  

3) BMP receivers (like routers when needing to reapply a policy) sometimes need 
to get a refresh for a subset of peers.   For example, a DB change that results 
in some peers needing to be added again.   Currently, the method to refresh 
are: 

   a) go to the router and initiate a route-refresh, which is intrusive and
  requires auth to do this. Not great.
   b) reset the BMP TCP connection to trigger the router to refresh everything.
  This is not ideal as there can be hundreds of peers and only a small set 
needed to be refreshed. 


IMO, the same solution can be used to solve for all of the above.   I would 
like to see a new BMP message that the receiver sends on initial connect to 
indicate what's needed.  It's important to call out that not all peers (by 
afi/safi) are equal in terms of buffer exhaustion during connection loss to a 
receiver.   For example, link-state, public/private peering with customers, 
etc… do not have many updates over several minutes.  An all-or-nothing approach 
based on short-time is not a desired solution (IMO) and leaves many other RIB 
dump use-cases unaddressed.  

Thanks,
Tim


On 3/11/21, 8:45 PM, "GROW"  wrote:


Hi Jakob,
 
➢ When processes abort unexpectedly, loss must be assumed unless data integrity 
can be specifically proven.
 
Absolutely. We need to distinguish between application and transport. At 
transport we do have sequence numbers and integrity on transport is ensured. On 
BMP application it is not. Here we need to distinguish between BMP application 
and BMP session. In a previous message to you I wrote:
 
➢ What I 

Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

[Tim Evens (tievens)]

Hi Warren,

I have just submitted revision 10 with the updates.

Thanks,
Tim


On 2/24/21, 3:18 PM, "Warren Kumari"  wrote:



On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) 
mailto:tiev...@cisco.com>> wrote:
Hi Warren,

Thank you so much for the review.   We agree with those changes. We have made 
the requested changes, but we cannot submit them until after Mar-8th.  Until 
then, I have attached a text diff output.  You can also see the changes at 
https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You can compare tag 
revisions.

Awesome, thank you very much. Please let me know LOUDLY once you've submitted, 
and I'll kick off IETF LC. It will probably have to wait until just after IETF 
ends, so that people can pay attention...

Thank again for the quick turn around,
W



Thanks,
Tim

On 2/22/21, 9:27 AM, "Warren Kumari" 
mailto:war...@kumari.net>> wrote:

Hi authors and WG,

Thank you for this document, I believe that allowing BMP to share Loc-RIB is 
clearly a good thing.

I do have a few comments/nits that addressing now should help the IETF
LC and IESG eval go more smoothly.

Please SHOUT loudly once you've had a chance to address these.

AD Review of draft-ietf-grow-bmp-local-rib


1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
I'm unable to parse this - changing "As shown in Figure 2, Locally originated" 
into "As shown in Figure 2, Locally Originated into Loc-RIB, ..." doesn't fix 
it, because the figure doesn't really "show what Sec 9.4 of RFC4271" says.
Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB) illustrates 
how redistributed or otherwise originated routes get installed into the Loc-RIB 
based on the decision process selection in [RFC4271]"


2: In Section 1.1 the document says things like: "The current method introduces 
the need..."
Once the document is published, the phrase "the current method" seems 
incorrect, but I don't have a better suggestion...

3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance peer 
type."
Should this be "locally sourced BGP routes"? It would be silly to think that 
this might carry e.g OSPF only routes, but you have a MUST, so important to be 
explicit.
This also seems to conflict with "The F flag indicates that the Loc-RIB is 
filtered". Perhaps that above is better worded something like:
"If locally sourced routes are communicated using BMP, they MUST be conveyed 
using the Loc-RIB instance peer type." ?

4: " The Loc-RIB contains all routes selected by the BGP protocol Decision 
Process section 9.1 of [RFC4271]."
Similar to #1 - perhaps this is just missing a "in section of..."? Still needs 
rewording.

5: "These routes include those learned from BGP peers via its Adj-RIBs-In 
post-policy, as well as routes learned by other means section 9.4 of [RFC4271]."
Similar -- I suspect that there was an errant search and replace which 
clobbered some text?

6: "Peer AS: Set to the BGP instance global or default ASN value."
Erm, what's this default ASN value?

7: "5.1.  Per-Peer Header"
I think that this section needs a pointer to RFC7854 Sec 4.2.

8: "Capabilities MUST include 4-octet ASN"
s/include 4/include the 4/

9: "For example, prefix 10.0.0.0/8<http://10.0.0.0/8> is updated "
Please use RFC5737 examples instead.


Nit:
1: "This is overly complex for such a simple application that only needed to 
have access to the Loc-RIB."
s/needed/needs/

2: It can greatly reduce time to troubleshoot and resolve issues if operators 
had the history of Loc-RIB changes.
s/had/have/

3: "BGP Instance: it refers to an"
s/it//

--
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky


--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

[Tim Evens (tievens)]

Hi Warren,

Thank you so much for the review.   We agree with those changes. We have made 
the requested changes, but we cannot submit them until after Mar-8th.  Until 
then, I have attached a text diff output.  You can also see the changes at 
https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You can compare tag 
revisions.

Thanks,
Tim

On 2/22/21, 9:27 AM, "Warren Kumari"  wrote:

Hi authors and WG,

Thank you for this document, I believe that allowing BMP to share Loc-RIB is 
clearly a good thing.

I do have a few comments/nits that addressing now should help the IETF
LC and IESG eval go more smoothly.

Please SHOUT loudly once you've had a chance to address these.

AD Review of draft-ietf-grow-bmp-local-rib


1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
I'm unable to parse this - changing "As shown in Figure 2, Locally originated" 
into "As shown in Figure 2, Locally Originated into Loc-RIB, ..." doesn't fix 
it, because the figure doesn't really "show what Sec 9.4 of RFC4271" says.
Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB) illustrates 
how redistributed or otherwise originated routes get installed into the Loc-RIB 
based on the decision process selection in [RFC4271]"


2: In Section 1.1 the document says things like: "The current method introduces 
the need..."
Once the document is published, the phrase "the current method" seems 
incorrect, but I don't have a better suggestion...

3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance peer 
type."
Should this be "locally sourced BGP routes"? It would be silly to think that 
this might carry e.g OSPF only routes, but you have a MUST, so important to be 
explicit.
This also seems to conflict with "The F flag indicates that the Loc-RIB is 
filtered". Perhaps that above is better worded something like:
"If locally sourced routes are communicated using BMP, they MUST be conveyed 
using the Loc-RIB instance peer type." ?

4: " The Loc-RIB contains all routes selected by the BGP protocol Decision 
Process section 9.1 of [RFC4271]."
Similar to #1 - perhaps this is just missing a "in section of..."? Still needs 
rewording.

5: "These routes include those learned from BGP peers via its Adj-RIBs-In 
post-policy, as well as routes learned by other means section 9.4 of [RFC4271]."
Similar -- I suspect that there was an errant search and replace which 
clobbered some text?

6: "Peer AS: Set to the BGP instance global or default ASN value."
Erm, what's this default ASN value?

7: "5.1.  Per-Peer Header"
I think that this section needs a pointer to RFC7854 Sec 4.2.

8: "Capabilities MUST include 4-octet ASN"
s/include 4/include the 4/

9: "For example, prefix 10.0.0.0/8 is updated "
Please use RFC5737 examples instead.


Nit:
1: "This is overly complex for such a simple application that only needed to 
have access to the Loc-RIB."
s/needed/needs/

2: It can greatly reduce time to troubleshoot and resolve issues if operators 
had the history of Loc-RIB changes.
s/had/have/

3: "BGP Instance: it refers to an"
s/it//


--
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
diff --git a/draft-ietf-grow-bmp-local-rib.txt 
b/draft-ietf-grow-bmp-local-rib.txt
index 2a3d66f..2f69495 100644
--- a/draft-ietf-grow-bmp-local-rib.txt
+++ b/draft-ietf-grow-bmp-local-rib.txt
@@ -6,13 +6,13 @@ Global Routing Operations 
  T. Evens
 Internet-Draft  S. Bayraktar
 Updates: 7854 (if approved)  M. Bhardwaj
 Intended status: Standards Track   Cisco Systems
-Expires: 18 July 2021 P. Lucente
+Expires: 28 August 2021   P. Lucente
   NTT Communications
- 14 January 2021
+24 February 2021
 
 
  Support for Local RIB in BGP Monitoring Protocol (BMP)
-draft-ietf-grow-bmp-local-rib-09
+draft-ietf-grow-bmp-local-rib-10
 
 Abstract
 
@@ -37,7 +37,7 @@ Status of This Memo
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 18 July 2021.
+   This Internet-Draft will expire on 28 August 2021.
 
 Copyright Notice
 
@@ -53,9 +53,9 @@ Copyright Notice
 
 
 
-Evens, et al. Expires 18 July 2021  [Page 1]
+Evens, et al.Expires 28 August 2021 [Page 1]
 
-Internet-Draft BMP Loc-RIB  January 2021
+Internet-Draft BMP Loc-RIB 

Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

[Tim Evens (tievens)]

Thanks.  I will update the draft as soon as it’s open again.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Job Snijders 
Sent: Friday, November 13, 2020 2:34:33 AM
To: Tim Evens (tievens) 
Cc: grow@ietf.org 
Subject: Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for 
sheperd write-up)

Dear Tim,

Hi Tim,

On Wed, Nov 04, 2020 at 05:49:48PM +0000, Tim Evens (tievens) wrote:
> [tievens] Agree. The draft itself has local in the name.  Does it make
> sense to change the draft name or keep it as is?

The filename is not relevant, I'd leave it as-is. Ultimately the
document will have an RFC number as filename anyway.

> [tievens] That works, but it's really the only method right now... hence 
> current... it becomes
>alternative with this draft. (  Changed to alternative.

Thanks. At this stage of the document's lifecycle it sometimes is
helpful to assume a writing style 'as if the document has been
published'. :-)

Thank you for the changes!

Can you upload a new revision next week?

Kind regards,

Job
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

[Tim Evens (tievens)]

Jeff, 

I've updated this to UTF-8. From a receiver point of view, we handle utf-8 
generically without any special need to deserialize it.  I suggest we do not 
attempt to define structure and/or constraints around the VRF names as that 
would severely impact system implementations that are out-of-scope of this 
draft. 

How about if we add:

"The structure, syntax, and constraints for a VRF name are router specific."


??

For example:

Type = 3: VRF/Table Name.  The Information field contains a UTF-8
string whose value MUST be equal to the value of the VRF or table
  name (e.g.  RD instance name) being conveyed.  The string size
  MUST be within the range of 1 to 255 bytes.  The structure, 
syntax,
and constraints for a VRF name are router specific.

Thanks,
Tim


On 11/3/20, 4:52 PM, "GROW on behalf of Jeffrey Haas"  wrote:

Job, 

I agree that utf-8 is more appropriate, but would remind you that a great 
deal more text about handling it would be needed. See prior discussion on RFC 
8203. 

Jeff

> On Nov 3, 2020, at 1:29 AM, Job Snijders
> 
> ### note 8
> 
> section 5.3
> 
> Curious: why ASCII and not UTF-8 (of which ASCII is a subset)?
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

[Tim Evens (tievens)]

I really appreciate your review and comments. These are great. 

See responses inline marked [tievens].


You can see the "pending" changes via: 
* https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/19/files
* 
https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/blob/rev-08/draft-ietf-grow-bmp-local-rib.txt


On 11/2/20, 10:14 PM, "GROW on behalf of Job Snijders"  wrote:

Dear group, authors

As part of the sheperd write-up I am reviewing the
draft-ietf-grow-bmp-local-rib-07 Internet-Draft. Overall the document
looks good to me.

Please consider these notes as input from an individual working group
participant. The suggestions are editorial in nature, my focus on
readability and clarity.

Thank you for your consideration!

Kind regards,

Job

### note 1

Suggested rewording of Abstract:

NEW Abstract:
The BGP Monitoring Protocol (BMP) defines access to various Routing
Information Bases (RIBs). This document updates BMP (RFC 8671) by
adding access to the Local Routing Information Base (Loc-RIB), as
defined in RFC 4271. The Loc-RIB contains the routes that have been
selected by the local BGP speaker's Decision Process. 

[tievens] Changes look good, but this draft doesn’t update 8671, it still 
updates 7854. 

### note 2

Throughout the document I would suggest changing the phrase
"Local-RIB" to "Loc-RIB".

[tievens] Agree. The draft itself has local in the name.  Does it make sense to 
change
the draft name or keep it as is? 


### note 3

Perhaps the first sentence of the introduction reads better if changed
to the following:

NEW:
This document defines a mechanism to monitor the BGP Loc-RIB state
of remote BGP instances without the need to establish BGP peering
sessions.

[tievens] Updated.


### note 4

I have trouble understanding the following:

The BGP Monitoring Protocol (BMP) suggests that locally originated
routes are locally sourced routes, such as redistributed or otherwise
added routes to the BGP instance by the local router. It does not
specify routes that are in the BGP instance Loc-RIB, such as routes
after best-path selection.

[tievens] I can see that.  Changed to: 

"BMP [RFC7854] does not define a method to send the BGP
instance Loc-RIB.  It does define in section 8.2 of [RFC7854] locally
originated routes, but these routes are defined as the routes
originated into BGP.  For example, locally sourced routes that are
redistributed."

### note 5

OLD:
Adj-RIBs-In Post-Policy may still contain hundreds of thousands of
routes per-peer but only a handful are selected and installed in
the Loc-RIB as part of the best-path selection.

NEW:
The Adj-RIB-In for a given peer Post-Policy may contain hundreds of
thousands of routes, with only a handful of routes selected and installed
in the Loc-RIB after best-path selection.

[tievens] Changed.

### note 6

Section 1.1. "Current method to Monitor Loc-RIB" probably needs to be
"Alternative method to monitor Loc-RIB"

s/current/alternative/

[tievens] That works, but it's really the only method right now... hence 
current... it becomes
alternative with this draft. (  Changed to alternative. 

### note 7

In section 3, the following change hopefully clarifies that the Loc-RIB
as observed through BMP is a composite of 
potentially-to-be-redistributed-into-BGP-routes
and routes received from other peers. 

OLD:
It is further defined that the routes selected include locally originated
and routes from all peers.

NEW:
Note that the Loc-RIB state as monitored through BMP might also contain 
routes
imported from other routing protocols such as an IGP, or local static 
routes.

[tievens] Nice. changed. 

### note 8

section 5.3

Curious: why ASCII and not UTF-8 (of which ASCII is a subset)?

[tievens] To be honest, ascii so that it's printable and works with 
iproute2/etc...  Although, 
   from a BMP perspective UTF-8 is more flexible and wouldn't restrict system 
implementations.
   Changed to UTF-8. VRF names will be system specific in terms of 
syntax/data-type, but from 
   a BMP receiver standpoint, we can easily, and should, support UTF-8.  

### note 9

Section 6.1 states "several methods to implement Loc-RIB efficiently"

is this the implementation of Loc-RIB in a BGP-4 speaker? Or the 
implementation
of BMP Loc-RIB monitoring?

[tievens] It is the speaker implementation.  I've changed it to 
"There are several methods for a BGP speaker to implement Loc-RIB 
efficiently."
Is this more clear? 



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW 

Re: [GROW] IPR call for draft-ietf-grow-bmp-local-rib

[Tim Evens (tievens)]

I am not aware of any IPR.  

Thanks,
Tim

On 8/16/20, 6:53 AM, "GROW on behalf of Job Snijders"  wrote:

Dear draft-ietf-grow-bmp-local-rib authors,

Are you aware of any IPR for draft-ietf-grow-bmp-local-rib?

IPR resources:
https://datatracker.ietf.org/ipr/about/
RFC 8179 "Intellectual Property Rights in IETF Technology" 
https://tools.ietf.org/html/rfc8179

Kind regards,

Job
Chair GROW

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Barry Leiba's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)

[Tim Evens (tievens)]

Hi Barry,

Thanks for catching that.  PR 
https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/pull/14 should 
correct this.  The rendered txt is 
https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/blob/iana_admin_label/draft-ietf-grow-bmp-adj-rib-out.txt

Thanks,
Tim

On 7/16/19, 9:46 AM, "Barry Leiba"  wrote:

Thanks, Paolo: the updates take care of the DISCUSS and all but one of
the editorial comments.  It's a little hard to tell from the github
PR, but it looks like the extra text in Section 9.3 is still there
(after the addition of "byte"):

<<
The Information field contains a free-form UTF-8 string whose byte
length is given by the Information Length field. The value is
administratively given by the Information Length field. The value
is administratively assigned. There is no requirement to terminate
the string with null or any other character.
>>

The second sentence appears to be a paste error and shouldn't be there... 
yes?

Thanks for addressing my comments!

Barry

On Tue, Jul 16, 2019 at 12:19 PM Paolo Lucente  wrote:
>
>
> Hi Barry,
>
> Thanks for your comments. I hope it is felt that the following edits 
address them:
>
> 
https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd
>
> Paolo
>
> On 10 Jul 2019, at 08:21, Barry Leiba via Datatracker  
wrote:
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-grow-bmp-adj-rib-out-06: Discuss
>
> 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-grow-bmp-adj-rib-out/
>
>
>
> --
> DISCUSS:
> --
>
> Two small points that will be trivial to address:
>
> — Section 4 —
>
>   The existing flags are defined in section 4.2 [RFC7854] and the
>   remaining bits are reserved for future use.  They SHOULD be
>   transmitted as 0 and their values MUST be ignored on receipt.
>
> Why “SHOULD”?  That’s inconsistent with Section 4.2 of 7854, which says 
“MUST”.
> Failing to set the reserved bits to 0 will cause interoperability problems
> with future extensions.
>
>   The following fields in the Per-Peer Header are redefined:
>
> You aren’t redefining them completely, right?  Don’t you mean, “When the 
O flag
> is set to 1, the following fields in the Per-Peer Header are redefined:” ?
>
>
> --
> COMMENT:
> --
>
> Some editorial comments:
>
> Throughout: there are five instances of “use-case”.  “Use case” should 
not be
> hyphenated (unless it’s used as a modifier, which it isn’t here).
>
> — Section 1 —
>
>   An example of pre-policy verses post-policy is
>
> You mean “versus”, with a “u” (and also a second time later in the 
section).
>
>   This document updates section
>   4.2 [RFC7854] per-peer header by adding a new flag
>
> That’s an odd way to do the citation.  Also, “per-peer header” is 
misplaced:
>
> NEW
> This document updates the per-peer header in section 4.2 of [RFC7854] by 
adding
> a new flag END
>
> The other places in the document that say “section 4.2 [RFC7854]” should 
also
> be changed to “section 4.2 of [RFC7854]”.
>
> — Section 6.3.1 —
>
>  The Information field contains a free-form
>  UTF-8 string whose length is given by the Information Length
>  field.
>
> As one UTF-8 character can be more than one byte, it’s best to specify 
whether
> the length is in bytes or characters.  I would say, “whose byte length is
> given” (also in Section 9.3)
>
> — Section 9.3 —
> The sentence, “The value is administratively given by the Information 
Length
> field.” appears to be a copy/paste error, and should be deleted.
>
>
>


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Routing Directorate Last Call Review for draft-ietf-grow-bmp-adj-rib-out-05.txt

[Tim Evens (tievens)]

Hi Acee,

Thank you so much for the review and diff of changes.  I've made all the 
requested changes.  We already had the terminology change from the art view.
We'll update the security section based on their review considering they may 
have some other suggestions.

You can see the changes at 
https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/pull/12/files .  
After the security review, we should be set to publish the final as revision 6.

Thanks!
Tim


On 6/20/19, 10:11 AM, "GROW on behalf of Acee Lindem (acee)" 
mailto:grow-boun...@ietf.org> on behalf of 
a...@cisco.com> wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-grow-bmp-adj-rib-out-05.txt
Reviewer: Acee Lindem
Review Date: June 20, 2018
IETF LC End Date: Not started yet.
Intended Status: Standards Track

Summary: The document extends BGP Monitoring Protocol to support per-peer 
Pre-Policy and Post-Policy Adj-RIB-Out monitoring similar to RFC 7854 support 
of Adj-RIB-In. The document is ready for publication.

Comments: A well-written clear and concise document.

Major Issues: N/A

Minor Issues:
Use updated boilerplate text for “Reserved Words”.

You will be undoubtedly asked to explain why the Adj-RIB-Out support 
doesn’t add any additional security considerations. However, I’ll leave that 
the security reviewers so that they can fulfill their divine mandate of 
securing the Internet.

Nits: See attached diff including Peer Up and Peer Down capitalization 
consistent with RFC 7854.

Thanks,
Acee






___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bmp-adj-rib-out-05

[Tim Evens (tievens)]

Hi Linda,

Thank you so much for your review and comments.  Please see response inline 
marked [tievens].


On 6/14/19, 1:44 PM, "Linda Dunbar via Datatracker"  wrote:

Summary:

The draft updates the BGP Monitoring Protocol BMP by adding access to the
Adj-RIB-Out RIBs. There are some unclear areas that need authors to clarify.

Major issues:

Minor issues:

Section 1 last paragraph:
It is not clear if BMP sender send to multiple BMP receivers  or just  to 
one
"BMP receiver". The first part of the sentence says "..send to a BMP
receivers", the second part says ".. advertise to BGP peers, .."

Suggest to make it consistent, such as sending  to multiple, or just one.   
"..
to send to BMP receivers what it advertises.."

[tievens] There are one or more receivers for each sender. The implementation 
defines how many receivers it can send to.   I've updated it to:

  "Adding Adj-RIB-Out provides the ability for a BMP sender to send to 
   BMP receivers what it advertises to BGP peers, which can be used for
   outbound policy validation and to monitor RIBs that were advertised."


Does a BMP sender also send out Adj-RIB-In? it is not clear to.

[tievens] Yes, RFC7854 defines Adj-RIB-In only.  How about the below?

  "BGP Monitoring Protocol (BMP) RFC 7854 [RFC7854] only defines Adj-
   RIB-In being sent to BMP receivers.  This document updates section
   4.2 [RFC7854] per-peer header by adding a new flag to distinguish
   Adj-RIB-In verses Adj-RIB-Out. BMP senders use the new flag to send
   either Adj-RIB-In or Adj-RIB-Out."


Section 6 first sentence: just curious which BMP messages are NOT 
applicable to
Adj-RIB-In or Adj-RIB-out?   If it is specified in other documents, please 
add
a reference.

[tievens] How about the below update to clarify some.   I didn’t want to create 
a list
of them because it could be different in updated/new drafts.

 "Many BMP messages have a per-peer header but some are not applicable
  to Adj-RIB-In or Adj-RIB-Out monitoring, such as peer up and down
  notficiations."



Nits/editorial comments:

Thank you.

Linda Dunbar



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Value of timestamps in BMP header for local-rib monitoring

[Tim Evens (tievens)]

Thanks Mukul. I'll also update this one as noted.

On 6/13/19, 8:16 AM, "GROW on behalf of Mukul Srivastava" 
mailto:grow-boun...@ietf.org> on behalf of 
msri=40juniper@dmarc.ietf.org> 
wrote:

Hi All

The current BMP Local-RIb draft doesn’t define what timestamp should be used in 
Per-Peer header for BMP local RIB monitoring.

BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:

Timestamp: The time when the encapsulated routes were received(one may also 
think of this as the time when they were installed in the Adj-RIB-In), 
expressed in seconds and microseconds since midnight (zero hour), January 1, 
1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
implementation-dependent.

The above timestamp use doesn’t make much sense for local RIB monitoring case.

Proposal:
1.  Since local RIB is not specific to a peer, the time stamp could be the 
time when BMP RM message was created or sent to BMP collector.
2.  Another option would be that the timestamp value be the time when this 
prefix was installed in local RIB.

Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
something like this:

   o  Timestamp: The time when the encapsulated routes were installed in
  The Loc-RIB, expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.
Thanks
Mukul
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Value of timestamps in BMP header for rib-out monitoring

[Tim Evens (tievens)]

Thanks Mukul, I'll update that as noted.

On 6/13/19, 6:17 AM, "Mukul Srivastava" 
mailto:m...@juniper.net>> wrote:

Hi All

The current BMP Adj-RIB-Out draft doesn’t define what timestamp should be used 
in Per-Peer header for BMP ADJ-RIB-OUT monitoring.

BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:

Timestamp: The time when the encapsulated routes were received (one may also 
think of this as the time when they were installed in the Adj-RIB-In), 
expressed in seconds and microseconds since midnight (zero hour), January 1, 
1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
implementation-dependent.

The above timestamp use doesn’t make much sense for Adj-RIB-Out case. A better 
value for timestamp, would be the time when a prefix was advertised to a peer. 
Collector can use this time stamp to get some sense of “when a given prefix was 
advertised to a peer”.

Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
something like this should be added in the for BMP ADJ-RIB-OUT draft:

   o  Timestamp: The time when the encapsulated routes were advertised
  (one may also think of this as the time when they were installed
  in the Adj-RIB-Out), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

Thanks
Mukul
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AD review of: draft-ietf-grow-bmp-adj-rib-out

[Tim Evens (tievens)]

Hi Warren, 

Thanks for the feedback.  We are incorporating these changes in the next 
revision.  

--Tim

> On May 31, 2019, at 2:15 AM, Warren Kumari  wrote:
> 
> Hi there,
> 
> Thanks to the authors and WG for this document -- it provides a useful
> mechanism / enhancement, is well written, and easy to understand.
> 
> I do have a few editorial comments that I'd like to see addressed
> before starting IETF LC. Note that these are mostly nit type things,
> and could be handled by the RFC Editor; but fixing them now will both
> remove load from the RFC Ed, and also make it easier / more pleasant
> for people reading during IETF LC, directorate reviewers and the IESG
> (also, once people start complaining about editorial stuff it often
> spirals into larger issues :-)).
> 
> 1: "This document updates BGP Monitoring Protocol ..." - I think this
> is missing "the"
> 
> 2: "Adding Adj-RIB-Out enables the ability for a BMP sender... " - I
> suggest "provides the ability"
> 
> 3: "As with Adj-RIB-In policy validation, there are use-cases that
> pre-policy Adj-RIB-Out is used to validate and audit outbound
> policies."  - I find this sentence confusing. How is: "Similarly to
> Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can be used to
> validate and audit outbound policies."? Or can the sentence be
> reworded?
> 
> 4: "Some attributes are set only during transmission of the BGP
> message, e.g.  Post-Policy."  -- I don't think the "e.g. Post-Policy"
> bit makes sense here - perhaps "ie. Post-Policy" was what was
> intended? Or can that just be dropped (I don't think it adds
> anything).
> 
> 5: "In this use-case, there maybe hundreds of wholesale peers but a
> single peer could have represented the  group.
>  A single peer could be used to represent a group." -- duplicate?
> Also, "maybe" should be "may be".
> 
> Again, I fully get that these are nits / editorial issues, but
> addressing them now help avoid issues later in the process...
> 
> W
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

[Tim Evens (tievens)]

Hi John,

We will submit a revision update shortly that incorporates the below changes.

--Tim

On May 23, 2019, at 9:53 AM, John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>> 
wrote:

Hi Job and all,

On May 22, 2019, at 8:44 PM, Job Snijders 
mailto:j...@instituut.net>> wrote:

I'd like to ask that folks with skin in the game take a look and share
with the working group whether we are good to go, or follow up with
proposals for changes to the draft, or at least affirm outstanding
issues still remain.

The diff resolves the major issue I brought up in my December 15, 2018 email 
(https://mailarchive.ietf.org/arch/msg/grow/wA3Nkz2lw6obTH9fF1X2Mkm4INM) using 
the solution Paolo and I agreed later 
(https://mailarchive.ietf.org/arch/msg/grow/t6LKhCLc-E_awiVHowB4WDnMSps).

Looks like this minor comment wasn’t addressed: "By the way, shouldn't those 
"SHOULDs" be "MUSTs"? If not MUST, under what circumstances MAY they be 
omitted?” I did a quick grep of -03 for SHOULDs and to my eye, all of them can 
(and therefore SHOULD :-) be MUSTs, other than those in section 5.4.2 of which 
I think the first is fine and the second could just as well be “should” in 
lowercase. (Opinions vary on the proper use of SHOULD vs. MUST, but this is 
mine.)

This is separate from the best/active topic you asked about, but Jeff replied 
to that so I’m going to assume it’s being covered.

—John
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-adj-rib-out-03.txt

[Tim Evens (tievens)]

This update includes the IANA assignments and minor changes. 

Thanks,
Tim

On 12/19/18, 8:23 AM, "GROW on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : Support for Adj-RIB-Out in BGP Monitoring 
Protocol (BMP)
Authors : Tim Evens
  Serpil Bayraktar
  Paolo Lucente
  Penghui Mi
  Shunwan Zhuang
Filename: draft-ietf-grow-bmp-adj-rib-out-03.txt
Pages   : 10
Date: 2018-12-19

Abstract:
   The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
   In Routing Information Bases (RIBs).  This document updates the BGP
   Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
   Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
   RIB-In and Adj-RIB-Out.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-bmp-adj-rib-out-03
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-adj-rib-out-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-adj-rib-out-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-adj-rib-out (ends 2018.11.26)

[Tim Evens (tievens)]

Done...  This should be good to go.

On 12/18/18, 5:55 PM, "Job Snijders"  wrote:

On Wed, Dec 19, 2018 at 01:44:21AM +, Tim Evens (tievens) wrote:
> Just to confirm... I need to update the draft with the allocations by
> incrementing the revision or is that done as a separate process?

I am not sure there is rules or tradition in this regard, so feel free
to post a new version referencing these codepoints. It may help new
implementers. In the IANA Considerations you can describe that IANA made
early allocations, and which ones they are.

Later on in the process (shepherd write-up, directorate review, IETF
last call, IESG review, RFC Editor are yet to come!) the language in
that section will be adjusted to reflect the correct tense and make the
early allocations permanent (if the document makes it to the finish line
of course).

Kind regards,

Job


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-adj-rib-out (ends 2018.11.26)

[Tim Evens (tievens)]

Hi, 

Just to confirm... I need to update the draft with the allocations by 
incrementing the revision or is that done as a separate process?

Thanks,
Tim

On 12/18/18, 3:58 PM, "GROW on behalf of Job Snijders"  wrote:

Dear all,

We received only positive feedback from various distinct stakeholders
regarding advancing draft-ietf-grow-bmp-adj-rib-out towards RFC. I'd
like state that it appears there is consensus to advance. Thank you all
for your input.

Also, IANA has made early allocations for the code points specified in
draft-ietf-grow-bmp-adj-rib-out-02. Please review
https://www.iana.org/assignments/bmp-parameters for this information.
If you have implemented (parts of) draft-ietf-grow-bmp-adj-rib-out,
please using these freshly assigned codepoints!

We'll now work to advance the document to the next stage.

Kind regards,

Job

On Sat, Dec 01, 2018 at 06:02:57PM +0100, Job Snijders wrote:
> Hi all,
> 
> We have only three (positive) responses so far, I’ll let the WGLC run
> December 7th to allow opportunity for more responses.
> 
> Kind regards,
> 
> Job
> 
> On Fri, Nov 9, 2018 at 15:08 Job Snijders  wrote:
> 
> > Dear GROW,
> >
> > As suggested in the working group meeting in Bangkok,
> > draft-ietf-grow-bmp-adj-rib-out may ready for last call. The last call
> > will be 2 weeks ending November 26th, 2018.
> >
> > Abstract:
> >
> > The BGP Monitoring Protocol (BMP) defines access to only the
> > Adj-RIB- In Routing Information Bases (RIBs). This document updates
> > the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the
> > Adj-RIB- Out RIBs. It adds a new flag to the peer header to
> > distinguish Adj- RIB-In and Adj-RIB-Out.
> >
> > The document is at
> > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out
> >
> > Please review the document and provide feedback.
> >
> > Kind regards,
> >
> > Job & Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

[Tim Evens (tievens)]

Hi Jeff, 

I'm also sorry for the delay.  There have been some year end commitments that 
have taken my available cycles. 

See inline marked [tievens]


On 12/10/18, 2:32 PM, "Jeffrey Haas"  wrote:

[Note, message reordered and reformatted for quoting clarity]

Tim,

Thank you for your patience for my response.

On Tue, Nov 20, 2018 at 05:42:37AM +, Tim Evens (tievens) wrote:
> On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" 
 wrote:
> > Jeff Haas said:
> > > I do wish to get this point resolved.  We have inconsistent pressure 
from our own customer base as to whether they want to monitor best bgp vs.
> > > "please give me something to let me stop needing parallel BGP 
sessions for active route state".  
> > 
> > [Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe 
a method to send best ecmp group to BMP Station. 
> > BMP client can signal add-paths capability to BMP Station via BMP 
Peer UP message, then BMP Station will know that the client will send multiple 
NLRI for one destination.  
> > That is my understanding.  
> > Per my limited knowledge about BMP, I don't understand why we need 
"parallel BGP sessions for active route state", Sorry.  Can you explain it in 
detail?
>
> Best route for sure, unless add-paths is used. I would like to understand
> your use-case more... When you mention the customer has to use "parallel
> BGP sessions for active route state," are you saying that the customer
> needs to establish multiple "monitoring" BGP peering sessions in order to
> obtain what would have been available via BMP Adj-RIB-In Post Policy
> monitoring?

Today, customers running stock BMP (RFC 7854) often tend to have a parallel
BGP peering session with their routers to monitoring stations.  This permits
them, in many cases, to correlate the results of BGP received paths vs. path
selection.

[tievens] That sounds like what we have been doing as well... basically trying 
to use Adj-RIB-Out to monitor local-Rib, which hasn't worked too well, 
especially with originated in bgp data. 

Sticking with a simplified example with BGP running its path selection
solely on BGP routes, the active route in the system's RIB may end up being
non-BGP.  Typical examples are static routes, or IGP routes winning out over
BGP routes.  I.e. "administrative distance".

[tievens] IMO, the "active route in the system's RIB" is more of the FIB table, 
where it takes into account conflicting sources of data (ISIS, OSPF, BGP, 
static/direct, and any variance of multi-instances).  This convergence of route 
sources with preference/selection, IMO, is out of scope for BGP monitoring.  
BGP monitoring by itself is very important to monitor.  The monitoring station 
(bmp receiver) can apply admin preference between the available sources of data 
(bgp-ls with ISIS and OSPF) to identify which one is used over the other, but 
it'll never replace the "system rib/fib."  BGP Loc-RIB is just what BGP has 
across all afi/safi's.  IMO, we will always need to monitor BGP, ISIS, and 
OSPF, but we also do need FIB.  I see FIB monitoring including egress 
interface/port granularity (lag port, not just the lag interface), source 
identifier of protocol and protocol instance, etc.  Something will have to be 
done with FIB monitoring to also address the hashing/lb based on l4/input/etc.


The route used for forwarding will be the active route in the RIB.

[tievens] BGP Loc-RIB is what the router has in, or available to, BGP that 
would be sent to a peer. 

BGP itself will advertise the active route in most implementations in most
circumstances.

[tievens] Agreed. There will be cases where another protocol will be preferred 
over BGP's learnt entry. BGP will still advertise (to peer and Loc-RIB) prefix 
A via next-hop C but the router is actually forwarding prefix A via next-hop Z 
based on another protocol having better preference. 

The issue in a simplified example:
If the active route for a destination is a static route, a customer may want
to know this vs. the best BGP route.  This is needed to check why forwarding
is happening as expected.

[tievens] Agreed, but this is not "BGP loc-RIB" monitoring.  This would be FIB 
or System RIB monitoring which is different.  This in IMO requires egress 
interface level info, specifically to address the issue with lag ports/members. 
 This level of monitoring also does not need all the BGP attributes or be 
required to conform to BGP... What's available and needed depends on the route 
source.  For example, ISIS TLV's, static route locally significant attributes, 
etc.   The FIB/System RIB level monitoring can be

Re: [GROW] BMP loc-rib Peer-Type behavior

[Tim Evens (tievens)]

NOTE: Sorry for the delay... end of year commitments are pressing... Addressing 
these comments in descending order. 

See inline marked [tievens]


On 12/11/18, 1:05 PM, "GROW on behalf of Jeffrey Haas"  wrote:

Authors,

In section 4.1, we define a new peer type to cover the loc-rib.  This is
mostly a pointer to section 4.2 of RFC 7854.


  0   1   2   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer Type   |  Peer Flags   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Distinguisher (present based on peer type)   |
 |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Address (16 bytes)   |
 ~   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer AS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer BGP ID   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Timestamp (seconds)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Timestamp (microseconds) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My question is with regards to Peer AS and Peer BGP ID:

If either of those fields are altered on the router, what is the expected
behavior in BMP?

I have opinions, but would like to see yours. :-)

[tievens] Per this draft, the BGP-ID and ASN are set to the global/default 
value or based on VRF (Local-RIB it conveys).   The simple answer is if you 
change distinguishing (peer identity) values in the per-peer-header, you will 
need to send a PEER DOWN (using old values) and PEER UP (using new values). 
Regardless of this draft, if you send a new per-peer header with different 
values (sans type, flags, and timestamps), the receiver is likely going to 
treat that as a different peer. We/OpenBMP, and I believe others, use peer rd, 
peer addr, peer asn, and peer id as distinguishing identify for a peer, which 
enables us to multiplex different peers over the same TCP (bmp) stream. 




-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP loc-rib Peer-Type behavior

[Tim Evens (tievens)]

NOTE: Sorry for the delay... end of year commitments are pressing... Addressing 
these comments in descending order. 

See inline marked [tievens]


On 12/13/18, 10:58 AM, "Paolo Lucente"  wrote:


Hi Jakob, Jeff,

+1 for the peer down / peer up sequence for the scenario described (and in 
general for changes to the peer, like peer address?).

But not re-sending RMs after the peer up seems very unclean to me. True we 
can invent an extra mechanism to say hold on your routes, like Jeff says, but i 
see the extra complexity with that (do we really need it?): it would work if 
the BMP server is building RIBs out of received RMs but what about more 
streaming data scenarios? Not to speak that if there was a route flap in BGP, 
due to the OPEN, you are effectively hiding it. Not BGP Monitoring Protocol 
anymore.

[tievens] This is classic state exchange and the reason why a RIB dump is 
needed upon PEER UP. It is simple to exchange the current state.  IMO, it will 
be more complex to implement a reconciling method to sync the BMP server 
(receiver) based on delta changes from time T1 to Tn.  A reconciling method 
will require the router to track where the BMP server is in terms of the RIB 
state and to exchange updates relative to new connect time.  BGP doesn't even 
attempt to do this, for good reason!  I believe the confusion with Jakob's 
response is that he is thinking we (the receivers) are log endpoints, which is 
totally not true.  Logging BGP changes are only part of the monitoring.   We 
fully expect to use BMP to monitor the RIB states, just like we have been doing 
with MRT(TABLE_DUMP/BGP4MP_MESSAGE) and PCAP for the past several years. 


Paolo  

> On 13 Dec 2018, at 19:49, Jeffrey Haas  wrote:
> 
> Jakob,
> 
> On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote:
>> From: Jeffrey Haas  
>>> On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote:
 Sending a peer-down followed by a peer-up seems reasonable to me.
 Changing these requires a new OPEN message to neighbors, so everything
 is going to bounce anyway.
>>> 
>>> I think so as well.
>>> 
>>> But what of the route monitoring messages?
>> 
>> I would leave those alone. Sending them again adds no new information.
>> The BMP server can switch the ASN and BGP-ID on its own if it wants.
> 
> That's my impression too.  However, if the implementation treats the
> peer-down as an implicit flush it won't work cleanly.
> 
> This means that something in the header needs to indicate "I'm
> updating some state, hold on to your RMs".
> 
> -- Jeff
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP loc-rib Peer-Type behavior

[Tim Evens (tievens)]

NOTE: Sorry for the delay... end of year commitments are pressing... Addressing 
these comments in descending order. 

See inline marked [tievens]


On 12/13/18, 11:27 AM, "Jeffrey Haas"  wrote:

Jakob,

On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote:
> Wait, a BMP server is not a BGP peer. It does not replicate a routing 
table.
> It is a logger/processor of information. It doesn't "delete" older 
information,
> just because some newer information arrived.
> Its purpose it to tell you what happened at some time in the past,
> because you are trying to debug a problem or do some capacity planning
> or whatever. Just because a BGP router changed its BGP-ID does not mean
> that all the routes it had 2 days ago magically did not happen.


RFC 7854:
:A Peer Down message implicitly withdraws all routes that were
:associated with the peer in question.  A BMP implementation MAY omit
:sending explicit withdraws for such routes.

-- Jeff

[tievens] This is the expected behavior... we mark all RIB entries as 
withdrawn/stale upon peer DOWN/UP. Note, there is no guarantee that we will 
receive a peer down (e.g. router term or connection failure), so upon PEER up 
we mark previous entries as withdrawn.  We expect that a PEER up will be 
followed by a RIB DUMP with the current state of the RIB. We expect updates 
following the RIB DUMP that will reconcile and maintain the state.   RFC7854 
doesn't address the transient changes happening during the RIB dump.   For 
example, it takes 1 minute to complete the RIB dump but about the changes 
during that dump?  IMO, they should be buffered and replayed.  This is a topic 
that is not specific to this draft but does need to be addressed. 
 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP loc-rib Peer-Type behavior

[Tim Evens (tievens)]

NOTE: Sorry for the delay... end of year commitments are pressing... Addressing 
these comments in descending order. 

See inline marked [tievens]


On 12/13/18, 12:26 PM, "Jakob Heitz (jheitz)"  wrote:

Most of the routes will be deleted anyway.
Only the locally originated routes will remain.

I would suggest to keep the implicit withdraw behavior and not
to explicitly withdraw any loc-rib routes when they go away.
That means, the BGP speaker will send BMP loc-rib peer-down,
not withdraw any routes to BMP and resend the locally originated
routes again.


[tievens] As in the previous response, we have no choice but to clear the 
list/RIB and start over upon PEER DOWN/UP in order to maintain a consist 
Loc-RIB (e.g we are not just a log of history events, we are maintaining the 
RIB that should mirror the router's RIB state).  Local-RIB peer should not 
result in a DOWN just because one or more peers have gone down.  The expected 
behavior is that Loc-RIB peer will send withdraws or updates based on changes, 
as it would for Adj-RIB-Out. 
 

   I don't believe GR activates in this case, because when the ASN or
BGP-ID changes, a NOTIFICATION will be sent. Can someone confirm?

[tievens] A change in BGP-ID is a change in BMP peer header. This MUST require 
a peer DOWN and PEER UP.

Regards,
Jakob.

-Original Message-
From: Jeffrey Haas  
Sent: Thursday, December 13, 2018 11:26 AM
To: Jakob Heitz (jheitz) 
Cc: Paolo Lucente ; draft-ietf-grow-bmp-local-...@ietf.org; 
grow@ietf.org
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

Jakob,

On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote:
> Wait, a BMP server is not a BGP peer. It does not replicate a routing 
table.
> It is a logger/processor of information. It doesn't "delete" older 
information,
> just because some newer information arrived.
> Its purpose it to tell you what happened at some time in the past,
> because you are trying to debug a problem or do some capacity planning
> or whatever. Just because a BGP router changed its BGP-ID does not mean
> that all the routes it had 2 days ago magically did not happen.


RFC 7854:
:A Peer Down message implicitly withdraws all routes that were
:associated with the peer in question.  A BMP implementation MAY omit
:sending explicit withdraws for such routes.

-- Jeff


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

[Tim Evens (tievens)]

Hi Jeff, 

Best route for sure, unless add-paths is used. I would like to understand your 
use-case more... When you mention the customer has to use "parallel BGP 
sessions for active route state," are you saying that the customer needs to 
establish multiple "monitoring" BGP peering sessions in order to obtain what 
would have been available via BMP Adj-RIB-In Post Policy monitoring?


Thanks,
Tim

On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan"  wrote:

I do wish to get this point resolved.  We have inconsistent pressure from 
our own customer base as to whether they want to monitor best bgp vs.
"please give me something to let me stop needing parallel BGP sessions for 
active route state".  
[Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a 
method to send best ecmp group to BMP Station. 
BMP client can signal add-paths capability to BMP Station via BMP Peer UP 
message, then BMP Station will know that the client will send multiple NLRI for 
one destination.  
That is my understanding.  
Per my limited knowledge about BMP, I don't understand why we need 
"parallel BGP sessions for active route state", Sorry.  Can you explain it in 
detail?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Tim Evens (tievens)]

On 10/13/18, 5:28 AM, "GROW on behalf of Zhuangshunwan" 
mailto:grow-boun...@ietf.org> on behalf of 
zhuangshun...@huawei.com> wrote:

Qing,

Inline with [Shunwan].

Thanks,
Shunwan

From: Qing Yang [mailto:qy...@arista.com]
Sent: Saturday, October 13, 2018 2:27 AM
To: Jeffrey Haas 
Cc: Zhuangshunwan ; grow@ietf.org
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: 
draft-ietf-grow-bmp-local-rib-02.txt)

Right. And the locRib peer header doesn't really have way to do more than 1 
anyway.
[Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a 
method to send best ecmp group to BMP Station.
BMP client can signal add-paths capability to BMP Station via BMP Peer UP 
message, then BMP Station will know that the client will send multiple NLRI for 
one destination.
That is my understanding.

Correct.  The draft is not inventing another method to convey 
additional/best-routes.  BGP add-paths can be used to advertise the ECMP paths. 
 Note, this does not include ECMP where FIB is performing ECMP based on a 
single best-route next-hop/label/etc.   While add-paths supports sending 
non-best, IMO I would like the draft to restrict the usage of add-paths to only 
convey best-routes if using add-paths with local-rib.   IMO, FIB is out of 
scope for BMP.

--Tim
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Tim Evens (tievens)]

My original response might have not been that clear with regards to adding a 
new INFO TLV to indicate support of sending inactive NLRI's that are in 
conflict with another routing protocol.  Some implementations do not have an 
option to be so flexible, so they may only support one or the other.  By 
indicating the intent to the BMP receiver, we enable the receiver to handle the 
updates correctly. IMO, it would be ideal if the BMP sender can advertise and 
indicate in a peer header flag that **all** NLRI's in the RM BGP UPDATE are in 
conflict due to another routing protocol with a better preference.   

What I suggest is a new INFO TLV in the PEER UP to indicate: 

(a) the BMP local rib will include rib-failure NRLI's with a peer flag 
indicating not-used due to another routing protocol/direct/static, 
(b) will not send rib-failure NLRI's,  
(c) will send rib-failure NLRI's but will not support the peer flag

If the PEER UP doesn't include this INFO_TLV, it'll be treated as (c).

Thanks,
Tim 

On 10/11/18, 2:33 PM, "GROW on behalf of Tim Evens (tievens)" 
 wrote:


On 10/11/18, 2:23 PM, "Jeffrey Haas"  wrote:

[Trimming original thread to re-ask my core question.]

On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> The local RIB in BMP should only contain what is/would be 
used/installed.

From where?  BGP's best route? The routing table's active route?

It's the BGP best/selected route. 


> In other words, the local rib sent via BMP should not contain the
> suppressed prefixes that were not installed due to another routing
> protocol/direct/static having a better preference.

Which ties into the RFC question about where other protocols are 
injected
into the Decision Process.

If you read the RFC as literally saying it's injecting it into the 
Decision
Process (section 9.4), the LocRib should be the best route and thus the
active route regardless of whether it was learned from BGP or not.

RIB failures due to another routing protocol preference is limited in scope 
to specific AFI/SAFI's (e.g. mainly IPv4/IPv6 unicast/multicast). For this 
use-case of installation/rib-failures where the prefix would be used but cannot 
be installed seems to justify a flag/info_tlv to indicate that.   


[rest left in for future context]

-- Jeff

>   I think we should
> allow the implementation to suppress the inactive or to advertise the
> inactive prefixes.   We can use a per-peer flag to indicate that the
> NLRI's in the RM/BGP UPDATE are suppressed due to another routing
> protocol/direct/static having better preference.  We'll also need to 
add a
> new INFO TLV in the PEER UP to indicate the expected conveyance of
> inactive/rib-failure NLRI's. 
> 
> Unless others have hardship about adding this, I can do an update. 
> 
> 
> Thanks,
> Tim
> 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Tim Evens (tievens)]

On 10/11/18, 2:23 PM, "Jeffrey Haas"  wrote:

[Trimming original thread to re-ask my core question.]

On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> The local RIB in BMP should only contain what is/would be used/installed.

From where?  BGP's best route? The routing table's active route?

It's the BGP best/selected route. 


> In other words, the local rib sent via BMP should not contain the
> suppressed prefixes that were not installed due to another routing
> protocol/direct/static having a better preference.

Which ties into the RFC question about where other protocols are injected
into the Decision Process.

If you read the RFC as literally saying it's injecting it into the Decision
Process (section 9.4), the LocRib should be the best route and thus the
active route regardless of whether it was learned from BGP or not.

RIB failures due to another routing protocol preference is limited in scope to 
specific AFI/SAFI's (e.g. mainly IPv4/IPv6 unicast/multicast). For this 
use-case of installation/rib-failures where the prefix would be used but cannot 
be installed seems to justify a flag/info_tlv to indicate that.   


[rest left in for future context]

-- Jeff

>   I think we should
> allow the implementation to suppress the inactive or to advertise the
> inactive prefixes.   We can use a per-peer flag to indicate that the
> NLRI's in the RM/BGP UPDATE are suppressed due to another routing
> protocol/direct/static having better preference.  We'll also need to add a
> new INFO TLV in the PEER UP to indicate the expected conveyance of
> inactive/rib-failure NLRI's. 
> 
> Unless others have hardship about adding this, I can do an update. 
> 
> 
> Thanks,
> Tim
> 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Tim Evens (tievens)]

On 10/11/18, 9:35 AM, "GROW on behalf of Nick Hilliard"  wrote:

Jeffrey Haas wrote on 11/10/2018 17:19:
> "inactive due to having been learned from a different routing protocol".
> 
> Nick, would you clarify with an example?

route X is learned via e.g. ISIS with precedence A.

route Y is learned via BGP with precedence B.

FIB is programmed with route X because precedence A trumps precedence B. 
  Route Y is marked as inactive (i.e rib-failure on ios).

I.e. normal operation of route selection, but BMP records BGP, so 
there's inconsistency as far as BMP is concerned, just how that relates 
to where packets are directed on the box.


The local RIB in BMP should only contain what is/would be used/installed.  In 
other words, the local rib sent via BMP should not contain the suppressed 
prefixes that were not installed due to another routing protocol/direct/static 
having a better preference.  I think we should allow the implementation to 
suppress the inactive or to advertise the inactive prefixes.   We can use a 
per-peer flag to indicate that the NLRI's in the RM/BGP UPDATE are suppressed 
due to another routing protocol/direct/static having better preference.  We'll 
also need to add a new INFO TLV in the PEER UP to indicate the expected 
conveyance of inactive/rib-failure NLRI's. 

Unless others have hardship about adding this, I can do an update. 


Thanks,
Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

I don't see that RFC7854 specifically identifies that stat types cannot repeat. 
IMO, the RFC text suggests singular value, not an array of AFI/SAFI/VALUE 
entries.

Thanks,
Tim

On 10/8/18, 4:22 AM, "Zhuangshunwan" 
mailto:zhuangshun...@huawei.com>> wrote:

Hi forks,

Regarding AFI/SAFI aware stats, e.g. Type 9 defined in RFC7854：
: o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
:value is structured as: 2-byte Address Family Identifier (AFI),
:1-byte Subsequent Address Family Identifier (SAFI), followed by a
:64-bit Gauge.

Question:
When counting NLRIs for multiple address families being enabled on the same 
peer, we have 2 possible choices:
1) In a BMP Stats Reports message, carrying only one Type-9-TLV, and the Value 
field contains multiple (AFI, SAFI, 64-bit Gauge) triples;
2) In a BMP Stats Reports message, carrying multiple Type-9-TLVs, and each 
Type-9-TLV carrying one (AFI, SAFI, 64-bit Gauge) triplet.

Which one should we follow?

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Tim Evens (tievens)
Sent: Thursday, October 04, 2018 2:54 PM
To: Qing Yang ; Jeffrey Haas 
Cc: grow@ietf.org
Subject: Re: [GROW] A question about RFC7854 stats report

Hi Qing,

It's not really an "update" count, it's NLRI.I currently consider the 
rejected prefixes counter as the number of times NLRI's have been rejected by 
inbound policy, not a count of distinct prefixes rejected as it pertains the 
current RIB.  It's not a count of updates either as a BGP update contains 
multiple NLRI's.. This counter is a way to indicate that some or all the NLRI's 
in a given BGP update were rejected.

For example:
Single BGP UPDATE has 5 NLRI's, 2 NLRI's are rejected due to policy.

Prefix and route, IMO, needs to be clarified that it's not just a prefix…  It's 
an NLRI.Currently, only types 9 and 10 are AFI/SAFI aware… This should mean 
that all other counts are global to the peer across the address families.  For 
example, a peer with bgp-ls and ipv4 unicast should have types 0, 1, 2, 7, 8, 
and 12 values that include combined NLRI' counts.

When counting NRLI's we should be using AFI/SAFI aware stats as it's misleading 
and becomes less useful when multiple address families are enabled on the peer.

Type 8 and 10 are labeled as Loc-RIB but many have treated them as Post-RIB.  
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-02 indicates the use 
of Loc-RIB for "local rib."

The statistic types are per-peer.  This means that we could get a stat report 
for pre and post policy (e.g. stat type 7) counts/gauges.

IMO, it would be great to update RFC7854 statistic reporting section to clear 
up the multiple confusions around statistic reporting.

Thanks,
Tim

On 10/3/18, 3:03 PM, "GROW on behalf of Qing Yang" 
mailto:grow-boun...@ietf.org> on behalf of 
qyang=40arista@dmarc.ietf.org<mailto:qyang=40arista@dmarc.ietf.org>> 
wrote:

It we deem it to be really useful to have an accurate tracking of number of 
rejected prefixes, which I can imagine, then it is fine that this will require 
the retainment of rejected advertisements; in other words, if it is configured 
to discard, you cannot supply this stats.
Which argues for an additional. My request in my last email, the last line, was 
essentially, if we head towards that (i.e, add a new type to denote this, then 
the original type 0), for backward compatibility, properly should be renamed to 
indicate 'update' as versus 'prefixes', to be accurate.

On Wed, Oct 3, 2018 at 2:02 PM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
On Tue, Sep 25, 2018 at 01:36:24PM -0700, Qing Yang wrote:
> Well, I would argue that as an RFC, it should not be tied to a specific 
> implementation, particularly if it’s a restriction. For the records, Arista 
> implementation has the choice of not discarding such updates.

So, when your implementation is configured to discard updates, how do you
expect things to behave?

[mix of top and bottom post preserved for context]

-- Jeff

> At a minimum I’d suggest the wording to be changed to ‘updates’ rather than 
> prefixes to avoid confusion.
>
> > On Sep 25, 2018, at 1:27 PM, Jeffrey Haas 
> > mailto:jh...@pfrc.org>> wrote:
> >
> >
> >> On Sep 25, 2018, at 2:53 PM, Qing Yang 
> >> mailto:40arista@dmarc.ietf.org>> 
> >> wrote:
> >>
> >> But the 'rejected prefix due to a policy' really is a function of two 
> >> entity: the incoming updates, and the policy itself. Let us say, you 
> >> receive 10 prefixes from a peer, and the policy is rejecting 5, and you 
> >> show the counter as 5. Later on, you change the policy to accept all, 
> >> without receiving any update, shouldn't the rejected prefix due to policy 
> >> drop to 0 at this point, but then the counter will prevent

Re: [GROW] bmp rib-out pre-policy questions (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-02.txt)

[Tim Evens (tievens)]

On 10/4/18, 12:41 PM, "GROW on behalf of Jeffrey Haas"  wrote:

:   Depending on BGP peering session type (IBGP, IBGP route reflector
:   client, EBGP) the candidate routes that make up the Pre-Policy Adj-
:   RIB-Out do not contain all local-rib routes.  Pre-Policy Adj-RIB-Out
:   conveys only routes that are available based on the peering type.
:   Post-Policy represents the filtered/changed routes from the available

The first one deals with the wording above.  I suspect what is intended to
be said is effectively that the route considered might not be a BGP route?

 No, it's related to how some prefixes will be advertised while others will
not, caused by peering type not egress policies. For example, IBGP 
excludes  
routes depending on reflector configuration.  This text is trying to 
articulate
to keep it simple and consider prefixes as candidates for Pre-Policy 
based
on the peer configuration.  If using RR-client, then include reflected
routes, but if not, then don't include those in the pre-policy.  
Post-Policy
is supposed to represent the egress policy filtered/modified 
NLRI's/attributes.
This is to support policy assurance/validation (diff of pre vs post)
If Adj-RIB-Out Pre-Policy included all local-rib candidate routes 
without
regard to peering type, then a compare/diff of pre to post policy RIB's
would render several routes missing, but are not missing/dropped by the
egress policy.  This leaves a gap in knowing why those routes are 
missing. 
Instead of trying to complicate it, the Adj-RIB-Out Pre-Policy should
represent the routes that would actually be advertised sans an egress
policy. In other words, the Adj-RIB-Out Pre-Policy is exactly what would
be advertised had there been no egress policy applied. This is
peer specific.

I think this is motivated by the somewhat sloppy meaning of loc-rib in 
RFC 4271 with respect to non-BGP routes.  Section 9.4 in there tries to
clarify what happens when you want non-BGP information to be injected
(redistribution), but the wording of the Decision Process largely restricts
itself to discussing Adj-Ribs-In.

This isn't a new issue, it generated a lot of noise during 4271's work in 
IDR.

Where this leads to some interesting ambiguity, and will have impact also in
the loc-rib doc (comments sent separately), is whether we're reporting on
what systems typically consider the "active" route vs. the best bgp route.

The second issue is distinct from the wording above, active or even best
bgp route.  I suspect that what is typically desired for telemetry purposes
is "show me the 'before' view of the route that we're actually advertising
in post-policy".  This may be very distinct from active or best bgp in some
scenarios.  A few examples include:
- best-external feature
- add-paths

 Adj-RIB-Out Pre-Policy should be the routes that would be advertised had
there been no egress policy applied.  The question of best, add-paths, 
...
shouldn’t change this as that would be based on the peering 
configuration.
There are some folks that are having a hard time with understanding how
we take peering configuration into account, but IMO, we (a) can get some
of this via the OPEN messages in PEER UP and (b) consider 
configuration. 
No network (or system for that matter) is managed or monitored by a 
single
method of collection. I fully expect and plan that we will be using
netconf/restconf/gNMI/whatever to correlate configuration to operational
 state/monitored data via BMP, similar to ipfix.  I do not
believe we need to complicate BMP to include configuration as we
have better means to obtain that. I consider the OPEN messages in PEER 
UP
operational (not config) as they are a way for us to discover the
session parameters and capabilities advertised.  It is important that 
we do
have a clear method to correlate the two datasets together.
For example, BMP peer X == Configuration Peer X.


-- Jeff


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

Qing, 

I can also provide some input on the draft as there are ones we have been 
wanting to add as a correction to the existing types. 

Thanks,
Tim

On 10/4/18, 12:16 PM, "Jeffrey Haas"  wrote:

Qing,

On Thu, Oct 04, 2018 at 11:28:30AM -0700, Qing Yang wrote:
> Points well taken... NLRIs will be an improvement in terminology over
> prefixes, too?
> 
> And yes, type 8 as it is worded today, is the reason that I think one
> cannot derive the number of prefixes rejected by inbound policy from type 
7
> and 8. So I definitely agree with you that an update to RFC7584 would be
> helpful.

A trivial Internet-Draft, at least once 
draft-scudder-grow-bmp-registries-change
has gone through.  My suggestion is to gather a list of stats you might want
and kick off the draft.

-- Jeff


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Request for early allocation of code points for draft-ietf-grow-bmp-(local-rib|adj-rib-out)

[Tim Evens (tievens)]

Sorry for the dumb question, but should I now submit a formal general request 
to https://www.iana.org/form/protocol-assignment for first come first serve 
allocations?   If so, I can submit that right away.  I'll work with Cisco XE 
folks to correct their hijacked usage of this range.

Thanks,
Tim

On 10/4/18, 1:03 PM, "GROW on behalf of Jeffrey Haas"  wrote:

[Please note that this message covers prior discussion among the BMP
loc-rib/adj-rib-out authors and the grow chairs and ADs.  This is mostly to
make sure we are open in our process.]

There are currently multiple implementations of the BMP adj-rib-out and
loc-rib Internet-Drafts in progress.

As noted in draft-scudder-grow-bmp-registries-change, the registries for BMP
parameters at IANA are a bit restrictive.  That draft is working to address
the long-term issues. 

This e-mail is to note a formal request for RFC 7120 early allocation of the
code points for these documents so that interoperable implementations can be
shipped.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

Hi Qing,

Pre-Policy vs Post-Policy stat reports addresses this, but isn't so clear in 
RFC7854.  Compare the Adj-RIB-In gauge for pre-policy to post-policy and we 
have the number of NLRI's (prefixes) that did not make it through the policy.   
While this does indicate the number of prefixes that were "rejected" by policy, 
it does not provide insight into the number times the NLRI's were being 
rejected.  For example, Adj-RIB-In(Pre) minus Ajd-RIB-In(Post) is the gauge 
representing the rejected value…  Unless the policy has changed, this value is 
consistently the same every interval… but in reality, the policy is being 
bombarded by advertisements that are being rejected.  Without a counter for 
this, we can't obtain stats on the advertisements for a given peer.  We need 
both and have both if the implementation implements both pre-policy and 
post-policy stat reports (per-peer header indicates pre vs post).

Thanks,
Tim

  As mentioned in the other thread response, it's not clearly indicated that 
there could be on stat report for pre-policy counts and another for 
post-policy.Problem is that many


On 9/25/18, 11:54 AM, "GROW on behalf of Qing Yang" 
mailto:grow-boun...@ietf.org> on behalf of 
qyang=40arista@dmarc.ietf.org> 
wrote:

But the 'rejected prefix due to a policy' really is a function of two entity: 
the incoming updates, and the policy itself. Let us say, you receive 10 
prefixes from a peer, and the policy is rejecting 5, and you show the counter 
as 5. Later on, you change the policy to accept all, without receiving any 
update, shouldn't the rejected prefix due to policy drop to 0 at this point, 
but then the counter will prevent us from doing it, and thus the station would 
not know from this design?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

Hi Qing,

It's not really an "update" count, it's NLRI.I currently consider the 
rejected prefixes counter as the number of times NLRI's have been rejected by 
inbound policy, not a count of distinct prefixes rejected as it pertains the 
current RIB.  It's not a count of updates either as a BGP update contains 
multiple NLRI's.. This counter is a way to indicate that some or all the NLRI's 
in a given BGP update were rejected.

For example:
Single BGP UPDATE has 5 NLRI's, 2 NLRI's are rejected due to policy.

Prefix and route, IMO, needs to be clarified that it's not just a prefix…  It's 
an NLRI.Currently, only types 9 and 10 are AFI/SAFI aware… This should mean 
that all other counts are global to the peer across the address families.  For 
example, a peer with bgp-ls and ipv4 unicast should have types 0, 1, 2, 7, 8, 
and 12 values that include combined NLRI' counts.

When counting NRLI's we should be using AFI/SAFI aware stats as it's misleading 
and becomes less useful when multiple address families are enabled on the peer.

Type 8 and 10 are labeled as Loc-RIB but many have treated them as Post-RIB.  
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-02 indicates the use 
of Loc-RIB for "local rib."

The statistic types are per-peer.  This means that we could get a stat report 
for pre and post policy (e.g. stat type 7) counts/gauges.

IMO, it would be great to update RFC7854 statistic reporting section to clear 
up the multiple confusions around statistic reporting.

Thanks,
Tim

On 10/3/18, 3:03 PM, "GROW on behalf of Qing Yang" 
mailto:grow-boun...@ietf.org> on behalf of 
qyang=40arista@dmarc.ietf.org> 
wrote:

It we deem it to be really useful to have an accurate tracking of number of 
rejected prefixes, which I can imagine, then it is fine that this will require 
the retainment of rejected advertisements; in other words, if it is configured 
to discard, you cannot supply this stats.
Which argues for an additional. My request in my last email, the last line, was 
essentially, if we head towards that (i.e, add a new type to denote this, then 
the original type 0), for backward compatibility, properly should be renamed to 
indicate 'update' as versus 'prefixes', to be accurate.

On Wed, Oct 3, 2018 at 2:02 PM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
On Tue, Sep 25, 2018 at 01:36:24PM -0700, Qing Yang wrote:
> Well, I would argue that as an RFC, it should not be tied to a specific 
> implementation, particularly if it’s a restriction. For the records, Arista 
> implementation has the choice of not discarding such updates.

So, when your implementation is configured to discard updates, how do you
expect things to behave?

[mix of top and bottom post preserved for context]

-- Jeff

> At a minimum I’d suggest the wording to be changed to ‘updates’ rather than 
> prefixes to avoid confusion.
>
> > On Sep 25, 2018, at 1:27 PM, Jeffrey Haas 
> > mailto:jh...@pfrc.org>> wrote:
> >
> >
> >> On Sep 25, 2018, at 2:53 PM, Qing Yang 
> >> mailto:40arista@dmarc.ietf.org>> 
> >> wrote:
> >>
> >> But the 'rejected prefix due to a policy' really is a function of two 
> >> entity: the incoming updates, and the policy itself. Let us say, you 
> >> receive 10 prefixes from a peer, and the policy is rejecting 5, and you 
> >> show the counter as 5. Later on, you change the policy to accept all, 
> >> without receiving any update, shouldn't the rejected prefix due to policy 
> >> drop to 0 at this point, but then the counter will prevent us from doing 
> >> it, and thus the station would not know from this design?
> >
> > If you recall that in many cases in many implementations that rejected 
> > routes are discarded and no longer in the RIB at all, I suspect being a 
> > counter makes somewhat more sense to you.
> >
> > -- Jeff
> >
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] FW: New Version Notification for draft-zhuang-grow-monitoring-bgp-parameters-00.txt

[Tim Evens (tievens)]

Below are comments.



** Section 4, Extension of BMP Initiation Message:



I suppose there are two ways to encode bgp optional params and default 
behaviors. We could encode all in the single info TLV where the info length is 
the total length in bytes of all encoded sub-tlv's.  Alternatively, we could 
repeat the info TLV's where only a subset of the sub-tlv's are encoded.  BGP 
capabilities works this way today, which IMO is a bit of a pain because we have 
to support both.  IMHO, I would prefer to pick one.  For example, call out that 
only one TBD1 and TDB2 can be present in an init message.  This would require 
the single info TLV to encode all sub-tlv's. For example, info tlv TBD1 (bgp 
caps) length would encode all bgp caps as an array of param sub-tlv's.



TBD3 - TBD12 should probably refence (rfc/draft links) the attribute values 
indicated.  For example, local pref is well known and encoded as a 32-bit 
"unsigned" int.   This draft doesn't call out that it's unsigned or signed, but 
if we know it's referring to the local-pref attribute, then we know it's 
unsigned and the value range allowed.



Other than the above, it looks good from initial review.



Thanks,

Tim





On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:



Hi all,



We have uploaded two drafts on BMP extensions.



"draft-gu-grow-bmp-vpn-label" proposes the idea of using BMP to collect VPN 
labels for applications such as traffic optimization.



"draft-zhuang-grow-monitoring-bgp-parameters" proposes to use BMP to 
collect BGP parameters: capacity and default behavior. The capacity parameters 
(both enabled and not enabled) are reported to the BMP server for better 
network optimization. The default behavior parameters, such as vendor-specific 
protocol preferences, are reported for multi-vendor interoperation.



Comments and suggestions are welcome!





Thanks!



Yunan





___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] FW: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt

[Tim Evens (tievens)]

Some comments below.

** Section 1, Introduction:
"On the other hand, the labeled
VPN routes are exchanged beween PE and PE, which could have been
monitored by BMP but are currently not implemented due to the massive
data exchange between the monitored devices and the BMP monitoring
station."
 
We support monitoring L3VPN and EVPN today in OpenBMP.  For L3VPN, we normally 
see similar loads (data exchanges) as monitoring full IPv4 tables.  Can you 
elaborate on how the L3VPN exchange is more than monitoring eBGP IPv4 transit 
peering (full IPv4 RIB)? I normally measure the load by initial RIB dump and 
then the incremental rate per NLRI.Currently, I see a typical IPv4 peer 
(pre-policy) with an incremental load of 12 NLRI's per second on average.
 
** Section 2, Extension of BMP Peer Up Message:
"If the Information Type is VPN Label, allocated per interface per 
label, the 
Information field should include the VPN label (20 bits label and 4 
bits zero
padding) and the corresponding interface address, with the total length
specified in the Information Length field.  One label and one interface 
address
is allowed for each Information TLV."
 
Which interface address?
 
"If the Information Type is VPN Label, allocated per route per label, 
the
Information includes the VPN label (20 bits label and 4 bits zero 
padding)
and the corresponding route prefix, with the total length specified in 
the
Information Length field.  The prefix should be in VPNv4 address format.
One label and one prefix is allowed for each Information TLV." 

Isn't this forming a RIB now?  Makes sense if it's peer or interface wide label 
because that is at peer scope. Encoding prefixes becomes a RIB at this point. 
Considering it's encoded in VPNv4 format, why not just encode this as a normal 
update for that AFI/SAFI? My initial thoughts are to reuse the VPNv4 afi/safi 
(or labeled unicast)  BGP UPDATE message or create a new BMP type to encode VPN 
label to prefix mappings.
 
If the Information Type is VPN Label, allocated per next hop per label, the 
Information should include the VPN label (20 bits label and 4 bits zero 
padding) and the corresponding next hop address, with the total length 
specified in the Information Length field.  One label and one next hop address 
is allowed for each Information TLV.
 
This is also a RIB, but a rib of next-hops with associated labels, right?  
IMHO, encoding this as labeled unicast or as a new BMP type might make more 
sense.
 
** Section 3, Operation:

I believe this is also the same use-case used for egress peer 
engineering/segment-routing.  We do have a method to collect this today using 
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15 and 
https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-11 . Do you have some 
other examples for the other types proposed?
 

 
In general, as I understand this draft, it is a method to convey single label 
to X mappings (e.g label RIB). Where X is either peer, vrf, interface, 
route/prefix, next-hop, etc.  I'm leaning more towards a new BMP type instead 
of trying to convey this in peer up informational TLV's.  The original RFC7854  
draft doesn't completely define how to handle PEER UP's in terms of when to 
expect a new RIB dump or not.  Currently, a new peer up can indicate that we 
should set all previous NLRI's as withdrawn and to expect a new RIB dump.   
Overloading the PEER UP to convey label mappings could complicate this. 
 
The peer level labels might have overlap with egress peer engineering 
(https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15).
 
Thanks,
Tim


On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Hi all,

We have uploaded two drafts on BMP extensions. 

"draft-gu-grow-bmp-vpn-label" proposes the idea of using BMP to collect VPN 
labels for applications such as traffic optimization. 

"draft-zhuang-grow-monitoring-bgp-parameters" proposes to use BMP to 
collect BGP parameters: capacity and default behavior. The capacity parameters 
(both enabled and not enabled) are reported to the BMP server for better 
network optimization. The default behavior parameters, such as vendor-specific 
protocol preferences, are reported for multi-vendor interoperation.  

Comments and suggestions are welcome!


Thanks!

Yunan

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 16:05
To: Lizhenbin ; Mipenghui (Kevin Mi) 
; Jie Chen ; Zhuangshunwan 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; iq...@mail.ustc.edu.cn 
Subject: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt


A new version of I-D, 

Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Tim Evens (tievens)]

Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans 
the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't 
think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and 
multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) 
can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also 
can be used to monitor EPE and direct/static routes, which is a bit of a 
stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via 
BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change 
(advertised verses withdrawn) when the adjacency changes.  If the router dies 
or the control-plane fails in some way, we still see the NLRI change from the 
other side of the adjacency (perspective).

What we are missing is a BGP-LS "attribute" tlv (on local entries) for 
links/nodes that indicates the REASON why the LINK (also NODE) is withdrawn, 
but this is not available without changing the IGP protocol itself (e.g. 
new ISIS TLV) or by implementing a solution architecture that requires BGP-LS 
feeds from all ISIS/OSPF nodes.  As written, I see NMP (including 
Netconf/gNMI/telemetry) requiring sessions from all nodes since the targeted 
data is not available in ISIS TLV's today.   For example, the ISIS LSDB on 
node-A does not have any local (device specific) information from all the other 
nodes unless there are TLV's to convey that information.

Regarding requiring BGP-LS feeds from many or all nodes...  We need this 
regardless of this draft because of segment-routing/egress peer engineering.   
Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes 
(normally via a peering server) so that we can collect/monitor EPE (hopefully 
using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01). Adding 
LINK/NODE withdrawal/down reason should not overstep into 
YANG/Netconf/Telemetry.

"3.2.  Forwarding Path Disconnection"

This seems to be more of a fit for telemetry with interface/link monitoring.  
Although, if the link was working at some point and it goes down due to MTU or 
otherwise, the BGP-LS REASON attribute should be able to convey that.  BGP-LS 
wouldn't convey anything if the link was never established.  Currently, it's 
assumed that the link advertisement means it's established.  This could be 
changed if we added a LINK NLRI state TLV.   The LINK could be updated 
(advertised) multiple times, changing based on state.   If the LINK doesn't 
establish, the withdrawal could indicate the reason.

"3.3.  ISIS LSP Synchronization Failure"

If a new BGP-LS LINK attribute is used as mentioned above to convey LINK adv 
state, it should then be feasible to add a state to indicate inconsistency. If 
the link/adj changes to down, then the withdrawal LINK reason attribute could 
indicate the cause.

The BGP-LS reason and state tlv's would only apply to the links/nodes that 
originate from the BGP-LS speaker.  Other node/link advertisements would not 
have the attribute/tlv.   This is why the solution would recommend enabling 
BGP-LS feeds from nodes that matter enough to get this level of local info.  
This btw would solve a problem we have with BGP-LS today where optional TLV's 
are not present unless ISIS/OSPF have specific features enabled, such as 
traffic-engineering... even IPv4/IPv6 router ID's are not included unless 
enabled specifically (isis) per node.

"4.  Extensions of NMP for ISIS"

Most of the new messages are redundant to the existing BGP-LS advertisements 
and withdrawals.  Telemetry of course could also convey this…

The initiation message could lead to overloading it with all kinds of device 
specific info.   Some constraint is needed.

The per peer (adjacency) header is missing multi-topology.  BGP-LS includes the 
protocol type (e.g. CT) and MT (missing from this draft).

All in all, I believe the use-cases described have merit and I think we can do 
this with BGP-LS, which doesn't require BMP but could be used.

Thanks,
Tim


On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" 
mailto:grow-boun...@ietf.org> on behalf of 
gregskinner0=40icloud@dmarc.ietf.org>
 wrote:

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) 
Bof from IETF 52 (10 December 
2001) the meeting you were thinking of?  There are also references to an IAB 
meeting in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, 
Netflow that 
culminated in RFC 3535.

Robin,

Regarding the draft in question, I generally 

Re: [GROW] The new BMP drafts and new BMP functionality

[Tim Evens (tievens)]

Hi Yunan Gu,

On 4/23/18, 5:18 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  wrote:
 
Typically, it’s implementation-efficient to reuse the existing message type for 
carrying new information, however, as I try to understand the 
interpretation/mapping of the local-rib information into each existing message 
type, I find it a little bit difficult to follow. More specifically, the peer 
definition for the local-rib per-peer head is changed from the “actual peer” to 
an emulated peer.  Since all peers are emulated, the associated peer up/down 
notifications and route monitoring messages are all fabricated. I understand 
that such implementation can be technically workable, but for me it’s a little 
bit deviated from the “monitoring” purpose of BMP. In fact, the above mentioned 
concerns can be solved by a straightforward idea of proposing a new message 
type for carrying the local-rib. Thus, we can save the inconvenience of 
transforming the BGP speaker–based local-rib into the peer-based format 
messages. 


 I believe what you wrote is what we are proposing.  See below response
to emulated peer.  Implementations vary and how "one" generates the BMP common 
+ peer
header as it is not dictated in RFC7854.  For example, as per the current 
RFC7854
draft, for efficiency the peer header only needs to be initialized once 
(cached) 
at PEER UP. This includes open messages, peer type, peer flags, RD, info
TLV's, etc. In this case, setting the message type or flag is no more 
efficient.   


 Emulated peer is a pseudo logical peer that "represents" the 
local-rib.
Implementations that do this today, leverage "existing code," requiring little 
effort
to implement local-rib.  They do this by generating a local-rib peer that is 
like any
other peer with the exception of no state/session or peer type (iBGP vs eBGP)
restriction.  The update-group (of 1) adj-rib-out for this peer represents the
local-rib. The draft keeps it open to allow the sender to apply filters on this
peer, such as to exclude any IBGP learnt prefixes. In this case with filters,
a single flag indicates the conveyed local-rib does not represent the entire 
set.
All the drafts (7854, local-rib, adj-rib-out) do not attempt to address 
configuration
or policy conveyance, other than simple hints via INFO TLV's. IMHO, attempting 
to
convey and consequently standardize on policy configuration goes into the weeds.
This includes even a simple attempt to convey just the policy names, as names,
order, actions, etc... are not standard over all platforms/vendors. 
While I completely agree operators need to know which policy results in which
change/filter/etc... the conveyance of such does not have to be via BMP.  I 
would
rather use BMP to monitor and measure the results and use a global unique ID for
correlation of peers to policy/configuration. This would enable monitoring
to be correlated correctly to YANG/Openconfig configurations and policies.  IMO,
it's not just the egress NLRI/attribute policies, it's all of the configuration
that makes up the policy, such as setting next-hop self, add-paths, ...  We 
need more than peer specific policy config, we need the rest of the 
configuration
(e.g. VRF imports/exports). I do not believe we should overload BMP with 
configuration and policies conveyance.  BMP is to monitor BGP
(NLRI's and attributes) not convey policies or configurations. 

===

Back to the new “local-rib message”, as Henk also suggested, the new message 
can be designed as TLV based. I think that using the TLV based format is more 
flexible for carrying non-route information in addition to the route 
information within either local-rib, rib-in or rib-out messages. For example, 
in order to better understand how the routing policy configured actually 
worked, an action/policy TLV can be defined and added to each route. The need 
for carrying the routing policy and actions/decisions taken has also been 
raised by Ruediger and Thomas in previous emails. I think it will be quite 
beneficial to the operators to understand how their routing policies actually 
worked and thus it’s worth taking the need into consideration during the BMP 
design. In addition, considering the format consistency perspective, except for 
the pre-policy rib-in, which can be encapsulated using the original BGP Update 
PDUs and sent to the monitoring station, all the other rib, i.e., post-policy, 
local-rib and rib-out, need to be first transformed from the rib format into 
the Update PDU format and then encapsulated with BMP headers, thus we might as 
well transform the rib into TLVs.  

 First, changing the peer-header to TLV's is a fundamental change to
RFC7854 peer header, forcing a version change.  Second, this IMHO is a total
scope creep for BMP as BMP is the wrong place to be conveying policies which
are configurations and are vendor/platform specific.   Adding 

Re: [GROW] The new BMP drafts and new BMP functionality

[Tim Evens (tievens)]

Henk,

On 3/26/18, 6:13 AM, "GROW on behalf of Henk Smit"  wrote:


What the new drafts propose:

The new drafts introduce new ways to report routes from the Adj-RIB-Out
and Loc-RIB to bmp-stations.

The Adj-RIB-Out draft does that by using a flag from the BMP per-peer
header's flag-field. This new flag indicates that a reported route is
from the Adj-RIB-Out in stead of the Adj-RIB-In.
I don't like this.

 Utilizing a flag for this follows RFC7854 in that the peer being
monitored can convey either Adj-RIB-In or Adj-RIB-Out for Pre-Policy and
Post-Policy, hence flags L and O.  
   
===
 
The flags-field has only 8 bits. We were using 3 of them. This draft
uses a 4th. And the Loc-RIB draft introduces yet another flag. We'll
be running out of flags soon.

 I believe you missed that loc-rib draft updates RFC7854 by
making flags specific to the peer type.  We updated 7854 to change flags
to be specific by peer type while also not breaking the current
7854 draft/bmp version support of the existing peer types.  Hence,
the existing peer flags are unchanged and therefore do not require
a version change in BMP. Flags by peer type is introduced in
local-rib draft, which specifically introduces a new peer type to 
support this without breaking anything else. 

Below is from draft-ietf-grow-bmp-local-rib-01 where it indicates
flags are specific to the peer type. In other words, 8 bits available
per peer type.   I can see how the below can be overlooked, so we can update
the draft sections 4.1 and 4.2 to clearly indicate that flags are now
specific by peer type.

   8.2.  BMP Peer Flags

  This document defines a new flag (Section 4.2) and proposes that peer
  flags are specific to the peer type:

  o  The F flag indicates that the Loc-RIB is filtered.  This indicates
 that the Loc-RIB does not represent the complete routing table.


===
   
The Loc-RIB draft introduces a new peer-type, the so-called
"Loc-RIB Instance Peer". Note, we already had a "Local Instance Peer".
I don't find this naming very clear. I also don't like mixing three
different types of routes (In, Out, Loc) in the same message-type.

 Revision 01 changed this statement to specifically call out why a 
new peer type was introduced.  If this isn't clear, we can further clarify it
more, including adding that that flags are specific to the peer
type, not global. 


"A new peer type is defined for Loc-RIB to distinguish that it
   represents Loc-RIB with or without RD and local instances.
   Section 4.2 [RFC7854] defines a Local Instance Peer type, which is
   for the case of non-RD peers that have an instance identifier."

I agree that local-instance needs to be better clarified in RFC7854.  
We discussed with John why RFC7854 introduced local-instance peer and how it
is a bit misleading.  He mentioned it was added to support local instance/RD
peers (e.g. local vrf) where there isn't a route-distinguisher. Instead
a locally unique RD would be used.  In this local-instance case, it still can 
represent
a peer.   

BMP adoption by vendors and open-source (FRR, Bird, ...) has been moving at 
glacial 
rates, including Nokia's lack of support. While you might say you don't like 
the drafts,
including 7854, and that maybe it's the reason why vendors haven't implemented 
it... I would 
disagree.  We have been working with both vendors and customers for the past 3 
years to 
implement BMP.  The reason why BMP is not implemented is NOT because the drafts
don't work or cannot be implemented as defined, it's because vendors 
(including BIRD and FRR) didn't have the customer demand to prioritize it.  We 
have
been advocating with both vendors and customers to adopt BMP as the prefer 
method
for BGP monitoring.  Customers are now finally requesting it, which is likely 
why
you now have priority to implement it.


Changing the version, when it doesn't really need to changed, adds unnecessary
backwards compatibility complexity with existing and new implementations.  This
effects both sender and receiver implementations.  While I can update 
SNAS/OpenBMP
to handle the complexity with this, other large cloud/service providers have 
already
implemented their own non-public BMP receivers that would also have to be 
updated.  


Change of RFC7854 local-instance usage borders on, if not mandates, a version
changed.  Instead, I’m for a bis update, which we have been talking about with
John, to clarify the use of local-instance peer, that or deprecate it.  

It should be NOTED that there are many items we have talked about updating in
the RFC7854bis.  I would prefer a separate thread to talk about the bis related
items.  

=== 


The other comments are related to RFC7854 and suggest significant changes
requiring a re-write of BMP. Your comments have merit and we have
been talking about this regarding a BIS update instead of a 

Re: [GROW] Dropped Updates in BMP?

[Tim Evens (tievens)]

I +1 that this is covered by post-policy, but there are some caveats.   In 
order to determine what was "dropped/filtered/rejected/whatever" we do a simple 
diff between pre-policy and post-policy.  Caveat is that this requires the BMP 
sender implementation to support both pre & post policy at the same time. 
Currently JunOS supports this, but others do not. For BMP senders that do 
not implement both pre & post for the same neighbor/peer, we have to glean the 
post-policy by other means.  

I've run into a few support issues with folks that have been comparing 
Adj-RIB-In pre-policy to what the router shows via CLI (e.g. bgp sum counts).   
They understand the idea of post-policy but they were confused when they saw 
different counts on peers that had no filters/policy applied.   I explained to 
them that it was likely rejected prefixes, not filtered. They were still unsure 
and wanted to have a better understanding why there are so many rejected 
prefixes.   

BMP includes stat counters, such as duplicates, invalidate due to ...   I was 
able to show "quickly" via these counters that if you subtract the 
invalidated/duplicate counts from the total, you get the number of RIB entries 
shown in CLI.   In this case, the issue for them was AS Path loops.  I was able 
to provide them a query to show the pre-policy prefixes that were rejected by 
the router due to AS Path loop.  

In the above example, they didn't have post-policy turned on so we couldn't 
easily do a diff.   Had they had post-policy we could do a diff instead of 
querying for the specific entries that were rejected (known via the stat 
counters). 

Even with pre/post diffs and bmp stat counters, we still don't have a 
reject/filter reason associated per route/prefix.  Instead, we have to 
"determine" the reason based on the diff. 

I also had discussions with users regarding how they are only interested in the 
diff output of pre/post and not the post RIB itself.  

I believe there is value in possibly adding a new Adj-RIB-In-PostDiff 
table/conveyance, which would contain ONLY the NLRI's that are 
filtered/rejected.  If we had this table, we could add flags or something 
similar to indicate the reason the NLRI is in the diff table, such as rejected 
due to AS Path loop.   This might get a bit complicated though. 

Thanks,
Tim


On 3/20/18, 7:14 AM, "GROW on behalf of Jeffrey Haas"  wrote:

Job,


On Tue, Mar 20, 2018 at 01:52:23PM +, Job Snijders wrote:
> Hi all,
> 
> Reudiger Volk mentioned something interesting at the microphone
> yesterday about getting more visiblity into BGP UPDATES that are
> rejected/dropped somewhere in the policy chain transitioning from
> Adj-RIB-In to Loc-RIB.
> 
> To make a crude route-map example:
> 
> ip prefix-list allow-ebgp-in permit 192.0.2.0/24
> !
> route-map ebgp-in permit 10
> match ip address prefix-list allow-ebgp-in
> !
> route-map ebgp-in deny 20
> bmp-log-code 21438
> 
> It would be great to see what UPDATEs get dropped in "route-map ebgp-in 
deny 20".
> It would perhaps be quite useful if we can get to the point where you
> can even attach custom policy-exit codes to the "Dropped Updates" send
> in this new BMP feed. I can see how this makes operational life easier.

The "exit code" is fairly reasonable.  The "dropped updates" can be
problematic depending on what you meant.

If you meant that the routes were discarded and not kept as inactive,
implementations may need mirror mode support since the route would not be
stored in the RIB.

Routes that are simply rejected but stored in the rib (e.g. "keep all" in
JunOS) can be reported as part of post-policy monitor mode.


> 
> RFC 4271 Section 9.1: "The Decision Process selects routes for
> subsequent advertisement by applying the policies in the local
> Policy Information Base (PIB) to the routes stored in its
> Adj-RIBs-In. The output of the Decision Process is the set of
> routes that will be advertised to peers; the selected routes will be
> stored in the local speaker's Adj-RIBs-Out, according to policy."
> 
> Perhaps a series of BMP "PIB" drafts are in order?

PIB docs were mostly left out of scope except as a general abstraction to
talk about in the BGP standardization effort because no one can agree on The
One True Policy Engine.  See similar conversation occurring right now in the
rtgwg policy yang model.

> Is this worthy of a new BMP draft? Are there volunteers?

I'd suggest keeping the scope to the bmp-log-code.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

Sorry, I jumped to state compression since that would reduce the repeats even 
if they aren't the same in terms of attributes.

I completely agree that peer group is not always the same.  Hence we need the 
protocol to not limit what can be exported.

> On Jul 11, 2017, at 6:41 PM, Jakob Heitz (jheitz) <jhe...@cisco.com> wrote:
> 
> I said run-length-encoding.
> That's data compression, not state compression.
> The peers in a peer-group do not always get exactly the same updates.
> 
> Thanks,
> Jakob.
> 
> 
>> -----Original Message-
>> From: Tim Evens (tievens)
>> Sent: Tuesday, July 11, 2017 6:34 PM
>> To: Jakob Heitz (jheitz) <jhe...@cisco.com>; Jeffrey Haas <jh...@pfrc.org>
>> Cc: grow@ietf.org
>> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
>> draft-ietf-grow-bmp-adj-rib-out-00.txt)
>> 
>> 
>> 
>> On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)" <jhe...@cisco.com> wrote:
>> 
>>How about some compression, like run-length-encoding instead of peer 
>> groups to reduce the firehose?
>>A bunch of peers being sent nearly the same updates should compress very 
>> nicely
>>and you wouldn't get all the confusion that comes with peer-groups.
>> 
>> [TE] This is reasonable and per RFC78564 Route-monitoring is state 
>> compressed.  Adj-RIB-Out follows that
>> and supports both route-mirroring and route-monitoring.  The 
>> interval/throttle used for the state-compression
>> should be platform specific, but it should be documented so that we know the 
>> granularity to expect.
>> State-compression should help reduce the number of updates but monitoring 
>> 100 peers that belong to the
>> same update/peer group will likely be wasteful as there will be a lot of 
>> duplication.  In this case,
>> I go back to needing some engineering love.
>> 
>> IMO, it does not make sense to monitor all of those peers if they in fact 
>> are conveying the identical advertisements.
>> In either case, we need that peer group name in the PEER UP so that we can 
>> correlate the peers to groups for proper
>> de-duplication. Unless we are monitoring for software bugs, the engineering 
>> team/operators know which peers should
>> be monitored in order to get a proper group representation based on 
>> egress/export policies. Although, this does put
>> a bit of a burden on engineering deployment.
>> 
>> To address the engineering deployment use-case of monitoring only the 
>> peer-group (export policy), it would be nice
>> to ease the monitoring configuration with the ability on the router to 
>> dynamic select the peer to be monitored.  For
>> instance, under the peer-group configuration for BMP monitoring, enable 
>> "adj-rib-out best 2".  The router then would
>> select the best 2 peers that represent the peer-group advertisements. This 
>> can change over time as peers are added,
>> removed, or experience stability issues.  In terms of BMP, normal 
>> PEER_UP/PEER_DOWN with INFO TLV's would be used so
>> that the receiving system can easily correlate and de-dup as needed by 
>> peer-group.  If the doing peer-group
>> monitoring, the peer itself wouldn't matter as much.
>> 
>> Peer group (including template) monitoring is not limited to Adj-RIB-Out.  
>> The same use-case for monitoring the
>> peer-group for export policy can be said for Adj-RIB-In as well.   The same 
>> engineering/deployment configuration of
>> which peer is to be monitored for the peer-group name can be used for 
>> Adj-RIB-In as well. Easing this configuration
>> for groups is beneficial.
>> 
>> BTW… we absolutely need the OPEN message to convey the capabilities.  This 
>> is required to correctly parse the NRLI's
>> and attributes.
>> 
>> 
>> 
>> 
>>Thanks,
>>Jakob.
>> 
>> 
>> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)"  wrote:

How about some compression, like run-length-encoding instead of peer groups 
to reduce the firehose?
A bunch of peers being sent nearly the same updates should compress very 
nicely
and you wouldn't get all the confusion that comes with peer-groups.

[TE] This is reasonable and per RFC78564 Route-monitoring is state compressed.  
Adj-RIB-Out follows that
and supports both route-mirroring and route-monitoring.  The interval/throttle 
used for the state-compression
should be platform specific, but it should be documented so that we know the 
granularity to expect.  
State-compression should help reduce the number of updates but monitoring 100 
peers that belong to the
same update/peer group will likely be wasteful as there will be a lot of 
duplication.  In this case, 
I go back to needing some engineering love.  

IMO, it does not make sense to monitor all of those peers if they in fact are 
conveying the identical advertisements.   In either case, we need that peer 
group name in the PEER UP so that we can correlate the peers to groups for 
proper de-duplication. Unless we are monitoring for software bugs, the 
engineering team/operators know which peers should be monitored in order to get 
a proper group representation based on egress/export policies. Although, this 
does put a bit of a burden on engineering deployment. 

To address the engineering deployment use-case of monitoring only the 
peer-group (export policy), it would be nice to ease the monitoring 
configuration with the ability on the router to dynamic select the peer to be 
monitored.  For instance, under the peer-group configuration for BMP 
monitoring, enable "adj-rib-out best 2".  The router then would select the best 
2 peers that represent the peer-group advertisements. This can change over time 
as peers are added, removed, or experience stability issues.  In terms of BMP, 
normal PEER_UP/PEER_DOWN with INFO TLV's would be used so that the receiving 
system can easily correlate and de-dup as needed by peer-group.  If the doing 
peer-group monitoring, the peer itself wouldn't matter as much. 

Peer group (including template) monitoring is not limited to Adj-RIB-Out.  The 
same use-case for monitoring the peer-group for export policy can be said for 
Adj-RIB-In as well.   The same engineering/deployment configuration of which 
peer is to be monitored for the peer-group name can be used for Adj-RIB-In as 
well. Easing this configuration for groups is beneficial.

BTW… we absolutely need the OPEN message to convey the capabilities.  This is 
required to correctly parse the NRLI's and attributes.  



   
Thanks,
Jakob.

 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

Jeff,

On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas"  wrote:


In such cases - use the per peer rib-out.  I do believe it has good use
cases.  However, discussions with our customers have suggested that in most
cases it's excessively chatty and threatens to swamp the rib-in portion of
the control channel they're actually interested in.  For them, a general
indication of rib-out content is sufficient, even when there's some minor
variations with specifications they may be comfortable with.

[TE] IMO, limitations around transmission of X number of peers with *-rib-* 
monitoring should be BMP
 sender implementation specific.  I do not believe anyone in their right mind 
would configure a platform/sender
for *-rib-* on all peers, but you never know. This is why limits should exist, 
a line in the sand,
for the platform.   Limits that apply to one platform are not necessarily 
required to be applied to another.
We want to enable the ability to monitor the five collection points of BGP 
(Adj-RIB-In/pre, Adj-RIB-In/post,
Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the 
platform can't restrict combinations.

I'm also open to alternative encodings that permit better clustering of the
messages to avoid redundant noise.

[TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment will 
do.  I can't imagine any sizable network
that has been configured without design/engineering.  I do not believe or 
suggest that is different with
BGP monitoring.  BGP is big data, like IPFIX in that sense, and therefore 
should get some engineering love, 
not willy-nilly turn it on everywhere and hope for the best. 


--Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

The use-case to monitor Adj-RIB-Out for a peer-group is definitely something 
this draft
addresses but appears to need more clarification. 

Noisy and likely duplicate/wasteful, yes… if one configures every peer to send 
Adj-RIB-Out
for peers that convey the same data, to which is likely not what folks will do 
or what I would
recommend doing.  I believe this can be addressed by adding "Other 
Considerations" section to
explain how one should go about using adj-rib-out.  For example, in the 
use-case of monitoring
peer-group egress policy advertisements, which is what I believe you are 
addressing with your
comment, the operator should configure at least two reliable peers in a group
to be monitored. This provides redundancy should one peer fail. This would 
easily provide peer-group
level conveyance of the egress policy. What's missing is the peer-group name so 
that on
the receiving side we can correlate (group) the peers that represent the same 
peer-group. 
Providing we have the group name for the peer, the receiver can group the peers 
that have the same
group name.  If the use-case is only to monitor the peer-group policy, not 
specific overrides per peer,
then the receiver can easily de-dup the X (redundant) peers for a single 
representation of the peer-group.

This is use-case specific as there are use-cases where we need to still monitor 
each peer even if they are 
part of the same peer/update group.  

In either case, this is really a receiver knob to correlate based
on intended operator configuration/deployment.  Although we do need the 
peer-group advertised as part
of the PEER INFO TLV, which we talked about at the BoF.  This was meant to be 
added, but I forgot to
add that.

Based on your proposal statements, it seems that this is only a method to 
correlate/map peers, 
peers that still need PEER_UP/per-peer RM messages, into a group. IMO, this 
complicates 
both the implementation (router/sender) and the receiver unnecessarily 
considering we can accommodate
this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By 
adding
a PEER_UP info TLV to convey peer/update group name enables the receiver to 
easily correlate
peers that belong to the same group.  How we treat and understand those peers 
is very much specific to the 
operator configuration/deployment/implementation on the receiver side.   The 
operator can
decide if they just need one peer per peer-group or if they want fault 
tolerance by including more peers.
This allows both the peer-group monitoring as well as the cases where an 
operator needs
to monitor each individual peer within a peer group or otherwise. 


Thanks,
Tim


On 7/10/17, 2:15 PM, "GROW on behalf of Jeffrey Haas"  wrote:

Authors,

We briefly discussed this during the bar BoF for BMP last IETF.  My
apologies for not presenting text before this point.

While there are use cases where an end-user may want per-peer rib-out state,
some applications may not quite that level of granularity of information.
In many cases, it is sufficient to know what route will be sent to the peers
that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
for the remainder of this e-mail.)

In such cases, the adj-rib-out in its current form can be quite noisy.  It
effectively can turn the BMP feed into trying to squeeze the entire firehose
of BGP traffic through the straw of a single session.

I'd offer the following proposal for per-group BMP rib-out:

The Per-Peer BMP header (RFC 7854, section 4.2) gets a new "peer-type" of
"Rib-Out Group" (value TBD).

For this new value, the Peer Distinguisher is set to a system-wide group-ID.
The Peer-Address, Peer AS and Peer BGP ID is zero-filled.  The group-ID is
sufficient to determine the contents of the BGP data sent to the peer-group.

A new message is allocated, called "BGP Rib-Out Groups".
Its contents are:

Flags (1 byte), a Delete flag is specified.
Group-Id (8 bytes)
Group-Name Length (1 byte)
Group-Name A UTF-8 string of up to 255 bytes representing the group name.
Number of Peers (2 bytes)
Peer-List Section: (for each peer)
  Peer Type (1 byte)
  Peer Flags (1 byte)
  Peer Distinguisher (8 bytes)
  Peer Address (16 bytes)
  Peer AS (4 bytes)
  Peer BGP ID (4 bytes)

The peer-list section is filled as per RFC 7854, section 4.2.

The BGP Rib-Out Groups message should be sent prior to sending Route
Monitoring or Route  Mirroring messages.  However, the application should be
prepared to receive such messages without the group mapping.

A group mapping by ID may be updated by sending a replacement with the same
Group Id.

A group mapping may be deleted by sending a truncated message 

Re: [GROW] call for adoption draft-evens-grow-bmp-adj-rib-out

[Tim Evens (tievens)]

Hi John.

On 4/19/17, 12:42 PM, "GROW on behalf of John Kemp"  wrote:

>Just noticed these.  I'm curious why they weren't combined
>   into one.  Seems like it's the same topic.

[TE] The primary reason to have them separated was so that we can work on them 
independently of each other without becoming to monolithic with the updates.
   
>Other question was, just to make sure, this is everything.
>So you got PRE, LOC, and POST covered now, correct?

[TE] Yes and more.  We have Pre/Post-Policy RIB-In, Pre/Post-Policy RIB-Out, 
and Loc-RIB.  With these two additional drafts, we should have complete 
monitoring coverage for BGP of what the router "sees," what the router "does to 
received," what the router "sends," and what the router "uses."
   
>JohN Kemp

 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed change to BMP registry policies

[Tim Evens (tievens)]

On 3/29/17, 12:47 PM, "GROW on behalf of John G. Scudder" 
 wrote:

>I propose leaving Peer Flags the way they are, Standards Action. There are 
> only five unallocated flags, it seems reasonable to have a higher bar to 
> allocating one.

Can we assign per-peer header flags based on peer type?   Some of the flags are 
irrelevant based on peer type, such as local-rib type.  If FIB is added, that 
will likely result in a need for changed/additional flags.  The local-rib draft 
proposes flags based on type, with the removal of ones that are not applicable 
and addition of the F flag to indicate filtered.  

Thanks,
Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow