Hi John,
About loc-rib (abusing the thread a bit): that is correct. We are going to
bundle that with Jeff’s feedback (which i am working on processing).
Paolo
On 26 Jun 2019, at 17:45, John Scudder
mailto:jgs=40juniper@dmarc.ietf.org>>
wrote:
That diff looks fine to resolve the issue I
That diff looks fine to resolve the issue I raised.
I think the question raised in the thread "Value of timestamps in BMP header
for local-rib monitoring” is still outstanding? Though it’s been updated in the
GitHub repo, I don’t think it’s been published yet.
—John
On Jun 26, 2019, at 7:15 AM
Tim did this 6/7/2019 (june 7)
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-04
huazzah! moving forward I think is ok now?
-chris
co-chairy
On Sat, Jun 1, 2019 at 5:23 AM Tim Evens (tievens) wrote:
>
> Hi John,
>
> We will submit a revision update shortly that incorporates the below
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 a
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 outstandi
Job,
> On May 22, 2019, at 1:44 PM, Job Snijders wrote:
>
> Dear all,
>
> Part of the IETF process is to ensure all concerns have been addressed
> (and hopefully resolved). A concern was raised about "best vs active".
> My takeaway from the conversation at IETF 104's GROW session is that
> the
Dear all,
Part of the IETF process is to ensure all concerns have been addressed
(and hopefully resolved). A concern was raised about "best vs active".
My takeaway from the conversation at IETF 104's GROW session is that
there is significant interest to progress towards publication - and
both Jeff
Hi John,
> On 07 Feb 2019, at 21:06, John Scudder wrote:
>
> [ .. ]
>
>> Although not going in the ideal direction, for shorter-term I was thinking
>> about somewhat a mix of the two solutions you propose, to work as a Charon:
>> use a new reason code (or perhaps two, one for local terminate
(re-sending, not sure what happened to the Subject of the email in my previous
post)
Hi John,
Inline:
> On 07 Feb 2019, at 21:06, John Scudder wrote:
>
>> Perhaps a longer term plan, where we do also tackle the subject of TLV &
>> Route Monitor message?
>
> As in Henk's earlier (and still
Thanks for your reply, Paolo. My remarks below.
On Jan 23, 2019, at 9:04 AM, Paolo Lucente wrote:
>
> Hi John,
>
> [shared text] Ideally, i would like every BMP message type to have a
> (optional) TLV section, each with a own namespace. If the idea is shared, i’d
> look forward to see how to
Hi John,
[shared text] Ideally, i would like every BMP message type to have a (optional)
TLV section, each with a own namespace. If the idea is shared, i’d look forward
to see how to get there.
> On 15 Dec 2018, at 00:40, John Scudder wrote:
>
> [ .. ]
>
> One fix, I think the more expedient
Now that the holidays are safely (?) over, I'm bumping this topic (and the
previous message to it, which I assume everyone can find for themselves).
--John
> On Dec 17, 2018, at 4:37 PM, John Scudder wrote:
>
> One further thought to this:
>
>> On Dec 14, 2018, at 6:40 PM, John Scudder wrote
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
One further thought to this:
> On Dec 14, 2018, at 6:40 PM, John Scudder wrote:
>
> Issue 1. draft-ietf-grow-bmp-local-rib says:
> This doesn't make sense to me, since the definition of reason 2 in RFC 7854
> section 4.9 doesn't allow for any extra data:
> An alternate fix, somewhat m
Hi All,
I apologize for the late reply to the WGLC. I have a couple of comments I'd
like to raise. I'll start by saying that although I'm going to bring up a
couple problems with draft-ietf-grow-bmp-local-rib, I think at least the second
was inherent in RFC 7854, and I will start a different ma
Acee,
On Mon, Dec 10, 2018 at 10:45:15PM +, Acee Lindem (acee) wrote:
> Just because a piece of information is useful doesn't necessarily mean it
> should be part of the BGP local RIB. In many cases, the BGP process and
> the Global RIB are deaggregated. If we wish to overload BMP with returni
Hi Jeff,
On 12/10/18, 5:33 PM, "GROW on behalf of 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
[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 thi
Yes/Support.
Best Regards,
Zhenbin(Robin)
-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 09, 2018 10:13 PM
To: grow@ietf.org
Subject: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends
2018.11.26)
Dear
Hi all,
Have the authors and Jeff Haas managed to discuss (and maybe resolve) what
was raised by Jeff?
Let’s extend WGLC with another week - I’m also not seeing a lot of feedback
on whether this document should progress. GROW please take a look and let
the group know how the continue.
Kind regar
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 or
@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 14, 2018 3:46 AM
To: Job Snijders
Cc: grow@ietf.org
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 +, Job Snijders wrote:
> Dear G
Network Engineer
Tribe IT Clouds
thomas.g...@swisscom.com
-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 9, 2018 3:13 PM
To: grow@ietf.org
Subject: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends
Chairs,
On Fri, Nov 09, 2018 at 02:12:46PM +, Job Snijders wrote:
> 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 Monito
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
25 matches
Mail list logo
