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

From: Job Snijders <[email-masked]>
Date: Fri, 9 Nov 2018 14:12:46 +0000

Dear GROW,

As suggested in the working group meeting in Bangkok,
draft-ietf-grow-bmp-local-rib 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 the Adj-RIB-In
    and locally originated routes (e.g. routes distributed into BGP from
    protocols such as static) but not access to the BGP instance
    Loc-RIB. This document updates the BGP Monitoring Protocol (BMP)
    RFC 7854 by adding access to the BGP instance Local-RIB, as defined
    in RFC 4271 the routes that have been selected by the local BGP
    speaker's Decision Process. These are the routes over all peers,
    locally originated, and after best-path selection.

The document is at https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib

Please review the document and provide feedback.

The internet-draft authors should note that Jeff Haas contributed a
comment to the IETF 103 GROW jabber room that unfortunatly wasn't read
out loud. This comment should be considered input into the last call
process:

    jhaas> "For loc-rib draft, list discussion was over whether we should
    advertise active route vs. best bgp route. Best bgp route means
    that you still need an active bgp session to monitor actual bgp and
    doesn't simplify use case."
    https://www.ietf.org/jabber/logs/grow/2018-11-05.html

Kind regards,

Job & Chris

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 13 Nov 2018 14:46:22 -0500

Chairs,

>     https://www.ietf.org/jabber/logs/grow/2018-11-05.html

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".  

One possible outcome is the working group determines that they're wanting to
stick with "best bgp route" and I followup with a quick new doc that
provides nearly similar behavior with the different outcome.  But I'd much
rather get this as an option in the current document.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 16 Nov 2018 07:55:51 +0000

Dear GROW,

I fully support publication of both drafts. They are very useful and long awaited. We are looking forward to implement it on our network as soon as it is available from our vendors. 

Kind regards
Thomas Graf
____________________________________________________________________________
Network Engineer
Tribe IT Clouds
[email-masked]

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Friday, November 9, 2018 3:13 PM
To: [email-masked]
Subject: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

Dear GROW,

As suggested in the working group meeting in Bangkok, draft-ietf-grow-bmp-local-rib may ready for last call. The last call will be 2 weeks, ending November 26th, 2018.

Abstract:

The internet-draft authors should note that Jeff Haas contributed a comment to the IETF 103 GROW jabber room that unfortunatly wasn't read out loud. This comment should be considered input into the last call
process:

Kind regards,

Job & Chris

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

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 16 Nov 2018 09:25:39 +0000

Hi Jeff & GROWers,

Firstly, I support this draft.
Because some customers ask us for this feature, and we are also implementing this feature, let's share our thoughts on this point.

Inline with [Shunwan].

Best regards,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 14, 2018 3:46 AM
To: Job Snijders <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

Chairs,

On Fri, Nov 09, 2018 at 02:12:46PM +0000, Job Snijders wrote:
> The document is at 
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib
> 
[Shunwan] Based on the requirement of Huawei's customers, they want to monitor the selected NLRIs.
One usecase: If a router enable multiple (e.g. 6) parallel EBGP load balancing, and now there are 8 available candidate EBGP routes for one destination D. In this case, there will be 6 routes of the same destination D been selected, and some customers want to monitor all the selected NLRIs.

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? 
Thanks,
Shunwan

One possible outcome is the working group determines that they're wanting to stick with "best bgp route" and I followup with a quick new doc that provides nearly similar behavior with the different outcome.  But I'd much rather get this as an option in the current document.

-- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Tue, 20 Nov 2018 05:42:37 +0000

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" <[email-masked] on behalf of [email-masked]> wrote: