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

From: Job Snijders <[email-masked]>
Date: Wed, 22 May 2019 17:44:14 +0000

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 Haas and John Scudder seemed to indicate to have ideas for
text on how to resolve issues they saw.

Version -03 didn't receive any feedback on the WG, so it is not clear
to me whether we have converged on consensus or not.

A -02/-03 diff be found here
https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-local-rib-03.txt

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.

Kind regards,

Job

On Wed, Feb 20, 2019 at 6:49 AM Paolo Lucente <[email-masked]> wrote:
>
>
> Hi John,
>
> > On 07 Feb 2019, at 21:06, John Scudder <[email-masked]> 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 terminated session, one for remotely terminated session) since, as you said in your follow-up email, it is the more conservative and would give the most hope against what has been already coded. And make this/these new reason code(s) carry "additional data [that] would be TLVized. It would obviously need to have a registry created for it” so not to make all too “expedient” and revolving around the specifics of VRF/Table Name and draft-ietf-grow-bmp-local-rib.
> >
> > If I understand you correctly this seems fine to me. I guess the easiest way to be fully clear would be to rev the draft, and then we can have a look at the new text?
>
> I contributed some text in section 5.3 (and updated IANA considerations in section 8), see:
>
> https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/blob/master/draft-ietf-grow-bmp-local-rib.txt
>
> Look forward to your thoughts.
>
> Paolo
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 May 2019 14:05:23 -0400

Job,

> On May 22, 2019, at 1:44 PM, Job Snijders <[email-masked]> wrote:
> 
> Dear all,
> 

The outstanding issues remain.

Minimally, the work I have promised (and am delinquent on) is to send diffs to help the draft be more clear in a RFC-4271 sense as to what is being sent.  This at least removes the ambiguity of the current text.

With regard to actual resolution of active vs. "bgp best", I suspect that we'll end up with the draft covering one thing and implementations perhaps choosing which of the two options to send.  Noting this in a TLV for the peer-up message would be one possible way to encode this.

I intend to spend some time resolving open IETF work next week after the U.S. Memorial Day holiday.

-- Jeff

P.S. I don't know that I've made this point before, but a flavor of this conversation had happened during standardization of the BGP MIB.

---

From: John Scudder <[email-masked]>
Date: Thu, 23 May 2019 08:52:45 +0000

Hi Job and all,

On May 22, 2019, at 8:44 PM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:

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