[GROW] Re: [GROW]I-D Action: draft-ietf-grow-bmp-peer-up-04.txt

[John Scudder]

I’m not aware of any such claims. 

—John

> On Aug 20, 2024, at 7:31 AM, Paolo Lucente  wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Job, Chairs,
> 
> No, i am not aware of any IPR related to this document.
> 
> Paolo
> 
> 
>> On 20/8/24 06:36, Job Snijders wrote:
>> Dear authors,
>> 
>> As part of the sheperd write-up I ask you whehter you are aware of any
>> claims to intellectual property rights in relationship to this
>> internet-draft.
>> 
>> Please respond on-list
>> 
>> Kind regards,
>> 
>> Job
>> 
>>> On Tue, Jun 11, 2024 at 03:51:23PM -0700, internet-dra...@ietf.org wrote:
>>> Internet-Draft draft-ietf-grow-bmp-peer-up-04.txt is now available. It is a
>>> work item of the Global Routing Operations (GROW) WG of the IETF.
>>> 
>>>Title:   BMP Peer Up Message Namespace
>>>Authors: John Scudder
>>> Paolo Lucente
>>>Name:draft-ietf-grow-bmp-peer-up-04.txt
>>>Pages:   8
>>>Dates:   2024-06-11
>>> 
>>> Abstract:
>>> 
>>>RFC 7854, BMP, uses different message types for different purposes.
>>>Most of these are Type, Length, Value (TLV) structured.  One message
>>>type, the Peer Up message, lacks a set of TLVs defined for its use,
>>>instead sharing a namespace with the Initiation message.  Subsequent
>>>experience has shown that this namespace sharing was a mistake, as it
>>>hampers the extension of the protocol.
>>> 
>>>This document updates RFC 7854 by creating an independent namespace
>>>for the Peer Up message.  It also updates RFC 8671 and RFC 9069 by
>>>moving the defined codepoints in the newly introduced registry.  The
>>>changes in this document are formal only, compliant implementations
>>>of RFC 7854, RFC 8671 and RFC 9069 also comply with this
>>>specification.
>>> 
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-peer-up/__;!!NEt6yMaO-gk!GE59fMFU055xil5w4tTS-lqD267-X03KFqvxlN4-LkwVrblrNVtBQJz5f2VT_QjG8IyK7U-vNw$
>>> 
>>> There is also an HTMLized version available at:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-peer-up-04__;!!NEt6yMaO-gk!GE59fMFU055xil5w4tTS-lqD267-X03KFqvxlN4-LkwVrblrNVtBQJz5f2VT_QjG8IwgP9978A$
>>> 
>>> A diff from the previous version is available at:
>>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-peer-up-04__;!!NEt6yMaO-gk!GE59fMFU055xil5w4tTS-lqD267-X03KFqvxlN4-LkwVrblrNVtBQJz5f2VT_QjG8IxlNStNZA$
>>> 
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>> 
>>> 
>>> ___
>>> GROW mailing list -- grow@ietf.org
>>> To unsubscribe send an email to grow-le...@ietf.org
>> 
>> ___
>> GROW mailing list -- grow@ietf.org
>> To unsubscribe send an email to grow-le...@ietf.org
> 
> ___
> GROW mailing list -- grow@ietf.org
> To unsubscribe send an email to grow-le...@ietf.org
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

Re: [GROW] [Technical Errata Reported] RFC7854 (7703)

[John Scudder]

This seems right. Unless anyone else sees a problem with it, I’d say verify the 
erratum.

—John

> On Nov 16, 2023, at 5:24 AM, RFC Errata System  
> wrote:
> 
> 
> The following errata report has been submitted for RFC7854,
> "BGP Monitoring Protocol (BMP)".
> 
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7703__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxkogc1LdAbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$
> 
> --
> Type: Technical
> Reported by: Dhananjay S. Patki 
> 
> Section: 4.2
> 
> Original Text
> -
>  *  The L flag, if set to 1, indicates that the message reflects
> the post-policy Adj-RIB-In (i.e., its path attributes reflect
> the application of inbound policy).  It is set to 0 if the
> message reflects the pre-policy Adj-RIB-In.  Locally sourced
> routes also carry an L flag of 1.  See Section 5 for further
> detail.  This flag has no significance when used with route
> mirroring messages (Section 4.7).
> 
> Corrected Text
> --
>  *  The L flag, if set to 1, indicates that the message reflects
> the post-policy Adj-RIB-In (i.e., its path attributes reflect
> the application of inbound policy).  It is set to 0 if the
> message reflects the pre-policy Adj-RIB-In.  Locally sourced
> routes also carry an L flag of 1.  See Section 5 for further
> detail.  This flag has significance only when used with Route
> Monitoring messages.
> 
> Notes
> -
> The L flag is used to indicate whether the route monitoring update reflects 
> Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB-Out pre-policy or 
> post-policy (RFC 8671). It does not apply to any message other than the Route 
> Monitoring message.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC7854 (draft-ietf-grow-bmp-17)
> --
> Title   : BGP Monitoring Protocol (BMP)
> Publication Date: June 2016
> Author(s)   : J. Scudder, Ed., R. Fernando, S. Stuart
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

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

Re: [GROW] Last Call: (Revision to Registration Procedures for Multiple BMP Registries) to Proposed Standard

[John Scudder]

Thanks for catching the error, Tom. I’ve uploaded version 04 to correct it.

—John

> On Sep 21, 2023, at 12:28 PM, tom petch  wrote:
> 
> I cannot make sense of this.
> 
> The I-D updates the registries defined in RFC7854 saying
> 
>   *  BMP Peer Down Reason Codes
> ...
>   For each of these registries, the ranges 32768-65530 whose
>   registration procedures were "Specification Required" are revised to
>   have the registration procedures "First Come First Served".
> ==
> The I-D does not specify the section numbers in RFC7854  but it would appear 
> that Peer  Down Reason Codes are 10.8  according to the table of contents
> 10.8.  BMP Peer Down Reason Codes . . . . . . . . . . . . . . .  24
> 
> Erratum 7194 says
> 3
> 
> Section 10.8 says:
> 
>   Information type values 0 through 32767 MUST be assigned using the
>   "Standards Action" policy, and values 32768 through 65530 using the
>   "Specification Required" policy, defined in [RFC5226].  Values 65531
>   through 65534 are Experimental, and values 0 and 65535 are Reserved.
> 
> It should say:
> 
>   Information type values 0 through 127 MUST be assigned using the
>   "Standards Action" policy, and values 128 through 250 using the
>   "Specification Required" policy, defined in [RFC5226].  Values 251
>   through 254 are Experimental, and values 0 and 255 are Reserved.
> 
> Notes:
> 
> In Section 4.9 Peer Down Notification. The "Reason" field is defined as one 
> octet, while the IANA consideration section is defining values as 2-octets 
> range. This errata suggests updating the IANA registry, instead of the size 
> of the "Reason" field in the Peer Down Notification message to avoid breaking 
> existing implementations that use one-octet reason.
> ==
> 
> This update  seems to be a nonsense
> 
> Tom Petch
> 
> From: GROW  on behalf of The IESG 
> 
> Sent: 21 September 2023 14:29
> To: IETF-Announce
> Cc: grow-cha...@ietf.org; grow@ietf.org; war...@kumari.net; 
> draft-ietf-grow-bmp-registries-cha...@ietf.org
> Subject: [GROW] Last Call:  
> (Revision to Registration Procedures for Multiple BMP Registries) to Proposed 
> Standard
> 
> 
> The IESG has received a request from the Global Routing Operations WG (grow)
> to consider the following document: - 'Revision to Registration Procedures
> for Multiple BMP Registries'
>   as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2023-10-05. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>   making a change to the registration procedures for several
>   registries.  Specifically, any BMP registry with a range of
>   32768-65530 designated "Specification Required" has that range re-
>   designated as "First Come First Served".
> 
> 
> 
> 
> The file can be obtained via
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change/__;!!NEt6yMaO-gk!FLwMLxRv69NjMZrE7Gmros09Z1Hs2O9xtNiwJzefW_Wcc1wCaViUSVRhgO2mUrHbRdLT-ftdEekqaw$
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!FLwMLxRv69NjMZrE7Gmros09Z1Hs2O9xtNiwJzefW_Wcc1wCaViUSVRhgO2mUrHbRdLT-ftWcMWhGg$

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

Re: [GROW] I-D Action: draft-ietf-grow-bmp-registries-change-04.txt

[John Scudder]

This version removes "BMP Peer Down Reason Codes” from the list of affected 
registries, per Tom Petch’s 
IETF LC review.

Thanks,

—John

> On Sep 22, 2023, at 11:45 AM, internet-dra...@ietf.org wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Internet-Draft draft-ietf-grow-bmp-registries-change-04.txt is now available.
> It is a work item of the Global Routing Operations (GROW) WG of the IETF.
> 
>   Title:   Revision to Registration Procedures for Multiple BMP Registries
>   Author:  John Scudder
>   Name:draft-ietf-grow-bmp-registries-change-04.txt
>   Pages:   3
>   Dates:   2023-09-22
> 
> Abstract:
> 
>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>   making a change to the registration procedures for several
>   registries.  Specifically, any BMP registry with a range of
>   32768-65530 designated "Specification Required" has that range re-
>   designated as "First Come First Served”.
...
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-registries-change (ends 2019.06.12)

[John Scudder]

No I’m not. 

Thanks,

— John

> On Sep 11, 2023, at 9:30 PM, Job Snijders  wrote:
> 
> 
> Hi John,
> 
> Are you aware of any IPR related to this Internet-Draft?
> 
> Kind regards,
> 
> Job
> 
>> On Wed, Aug 16, 2023 at 07:29:25PM +, John Scudder wrote:
>> Jeff just reminded me about this. I see that although it passed WGLC it 
>> never got put into PubReq, and I forgot all about it, mea culpa. I’ve just 
>> version bumped it, I’d appreciate if one of the chairs would push the PubReq 
>> button (or whatever else you deem suitable to do next).
>> 
>> Thanks,
>> 
>> —John
>> 
>>>> On Jul 11, 2019, at 11:29 PM, Christopher Morrow 
>>>>  wrote:
>>> 
>>> With overwhelmingly positive response, let's move this forward!
>>> I'll see about sending the IESG bits forward in the next day.
>>> 
>>> Thanks!
>>> -chris
>>> 
>>> On Wed, May 22, 2019 at 1:25 PM Job Snijders  wrote:
>>>> 
>>>> Dear GROW,
>>>> 
>>>> We have a fairly short procedural document to consider for publication.
>>>> As suggested in the working group meeting in Prague,
>>>> draft-ietf-grow-bmp-registries-change may ready for last call. The last
>>>> call will be ~ 2 weeks, ending June 12th, 2018.
>>>> 
>>>> Abstract:
>>>> 
>>>>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>>>>   making a change to the registration procedures for several
>>>>   registries. Specifically, any BMP registry with a range of
>>>>   32768-65530 designated "Specification Required" has that range re-
>>>>   designated as "First Come First Served".
>>>> 
>>>> The document information is available at:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM&s=hiF3YdrDQkVvKOBhpXp-lwo9LMS3K917rWD5XqRnyiU&e=
>>>> HTML: 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM&s=UtFIov2lb8rHJhzfKNMPGgCc0b-eRXk0QHHYLLoP0Bw&e=
>>>> 
>>>> Please review the document and provide feedback.
>>>> 
>>>> Kind regards,
>>>> 
>>>> Job & Chris
>>>> co-chairs GROW
>> 
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/grow__;!!NEt6yMaO-gk!DZj20sKpEy3uFm1-e6cI4Jpa9vvN3_2daFGh84Z9gPmwYQqYqYcr0VoSvb6i-b_o6Bx02nkr$
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-registries-change-03.txt

[John Scudder]

The 02 version-bump was txt only, because I couldn’t work out why the upload 
page was rejecting my XML. I sorted out my problem and re-uploaded using the 
XML source. Other than the availability of the HTML rendering, 02 and 03 are 
identical (and are also identical to 01 but for expiration date). Sorry for the 
noise.

—John

> On Aug 16, 2023, at 4:01 PM, internet-dra...@ietf.org wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Global Routing
> Operations (GROW) WG of the IETF.
> 
>   Title   : Revision to Registration Procedures for Multiple BMP 
> Registries
>   Author  : John Scudder
>   Filename: draft-ietf-grow-bmp-registries-change-03.txt
>   Pages   : 3
>   Date: 2023-08-16
> 
> Abstract:
>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>   making a change to the registration procedures for several
>   registries.  Specifically, any BMP registry with a range of
>   32768-65530 designated "Specification Required" has that range re-
>   designated as "First Come First Served”.
[…]
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-registries-change-02.txt

[John Scudder]

This is just a version bump to refresh the document, which has already passed 
WGLC, see my note from a few seconds ago.

—John

> On Aug 16, 2023, at 3:25 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Global Routing
> Operations (GROW) WG of the IETF.
> 
>   Title   : Revision to Registration Procedures for Multiple BMP 
> Registries
>   Author  : John Scudder
>   Filename: draft-ietf-grow-bmp-registries-change-02.txt
>   Pages   : 3
>   Date: 2023-08-16
> 
> Abstract:
>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>   making a change to the registration procedures for several
>   registries.  Specifically, any BMP registry with a range of
>   32768-65530 designated "Specification Required" has that range re-
>   designated as "First Come First Served”.
[…]
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-registries-change (ends 2019.06.12)

[John Scudder]

Jeff just reminded me about this. I see that although it passed WGLC it never 
got put into PubReq, and I forgot all about it, mea culpa. I’ve just version 
bumped it, I’d appreciate if one of the chairs would push the PubReq button (or 
whatever else you deem suitable to do next).

Thanks,

—John

> On Jul 11, 2019, at 11:29 PM, Christopher Morrow 
>  wrote:
> 
> With overwhelmingly positive response, let's move this forward!
> I'll see about sending the IESG bits forward in the next day.
> 
> Thanks!
> -chris
> 
> On Wed, May 22, 2019 at 1:25 PM Job Snijders  wrote:
>> 
>> Dear GROW,
>> 
>> We have a fairly short procedural document to consider for publication.
>> As suggested in the working group meeting in Prague,
>> draft-ietf-grow-bmp-registries-change may ready for last call. The last
>> call will be ~ 2 weeks, ending June 12th, 2018.
>> 
>> Abstract:
>> 
>>This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>>making a change to the registration procedures for several
>>registries. Specifically, any BMP registry with a range of
>>32768-65530 designated "Specification Required" has that range re-
>>designated as "First Come First Served".
>> 
>> The document information is available at:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM&s=hiF3YdrDQkVvKOBhpXp-lwo9LMS3K917rWD5XqRnyiU&e=
>>  
>> HTML: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM&s=UtFIov2lb8rHJhzfKNMPGgCc0b-eRXk0QHHYLLoP0Bw&e=
>>  
>> 
>> Please review the document and provide feedback.
>> 
>> Kind regards,
>> 
>> Job & Chris
>> co-chairs GROW

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

[GROW] Soliciting review of Section 7 of draft-ietf-teas-rfc3272bis-24

[John Scudder]

Hi GROW (and cc TEAS, authors),

I’ve just requested IETF Last Call [1] for draft-ietf-teas-rfc3272bis-24 
("Overview and Principles of Internet Traffic Engineering”). In my AD review 
[2] I had several questions about Section 7, “Inter-Domain Considerations”. In 
particular, this one remains unresolved (this is a quote from the draft, 
followed by my comment, in case it’s unclear):

```
   When considering inter-domain TE with BGP, note that the outbound
   traffic exit point is controllable, whereas the interconnection point
   where inbound traffic is received typically is not.  Therefore, it is
   up to each individual network to implement TE strategies that deal
   with the efficient delivery of outbound traffic from its customers to
   its peering points.  The vast majority of TE policy is based on a
   "closest exit" strategy, which offloads inter-domain traffic at the
   nearest outbound peering point towards the destination AS.  Most
   methods of manipulating the point at which inbound traffic enters a
   are either ineffective, or not accepted in the peering community.
--
jgs: the last two sentences above seem to be [citation needed]. In 
particular, I had thought AS_PATH prepending was a pretty common 
practice. A very brief web search turned up a 2020 CAIDA paper that
seems to confirm this 
(https://www.caida.org/catalog/papers/2020_aspath_prepending/aspath_prepending.pdf)

At this point it occurs to me to ask whether the GROW WG was prompted
to review this section?
—
```

Adrian (the editor) suggested [3] that we solicit this input during IETF Last 
Call, which makes sense to me. So, please consider this your invitation to have 
a look at Section 7 and provide any feedback you may have.

Thanks in advance!

—John

[1] https://mailarchive.ietf.org/arch/msg/teas/agv93XBdaAcpONX6-AB42vROqF4/
[2] https://mailarchive.ietf.org/arch/msg/teas/rHvxm7Jv5j_btcNED5waqFgnKao/
[3] https://mailarchive.ietf.org/arch/msg/teas/fJrMWX0ZalySZjEiV8kNbr9wr60/
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7854 (7194)

[John Scudder]

Sorry about that. 

The erratum is legit, should be verified IMO. 

—John

> On Oct 30, 2022, at 4:32 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7854,
> "BGP Monitoring Protocol (BMP)".
> 
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7194__;!!NEt6yMaO-gk!AqnlC3TArN6GcXDLLA_xxBPotnjq95ygKIRNZvc6RVfL7k2bkLuK13B9ThqIG_4sUeUd1zQDH5ZhsEc-u4_0kQ$
> 
> --
> Type: Technical
> Reported by: Ahmed Elhassany 
> 
> Section: 10.8
> 
> Original Text
> -
>   Information type values 0 through 32767 MUST be assigned using the
>   "Standards Action" policy, and values 32768 through 65530 using the
>   "Specification Required" policy, defined in [RFC5226].  Values 65531
>   through 65534 are Experimental, and values 0 and 65535 are Reserved.
> 
> Corrected Text
> --
>   Information type values 0 through 127 MUST be assigned using the
>   "Standards Action" policy, and values 128 through 250 using the
>   "Specification Required" policy, defined in [RFC5226].  Values 251
>   through 254 are Experimental, and values 0 and 255 are Reserved.
> 
> Notes
> -
> In Section 4.9 Peer Down Notification. The "Reason" field is defined as one 
> octet, while the IANA consideration section is defining values as 2-octets 
> range. This errata suggests updating the IANA registry, instead of the size 
> of the "Reason" field in the Peer Down Notification message to avoid breaking 
> existing implementations that use one-octet reason.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC7854 (draft-ietf-grow-bmp-17)
> --
> Title   : BGP Monitoring Protocol (BMP)
> Publication Date: June 2016
> Author(s)   : J. Scudder, Ed., R. Fernando, S. Stuart
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[John Scudder]

FWIW I think I ended up capturing much of that in the erratum I submitted — but 
this conversation also illustrates why the fix has to be a new WG doc and not 
just an erratum.

Thanks,

—John

On Sep 14, 2022, at 4:55 PM, Jeffrey Haas  wrote:


On Sep 14, 2022, at 2:36 PM, John Scudder 
mailto:j...@juniper.net>> wrote:

That’s cleaner but now the monitoring station has to go to the (minor?) trouble 
of keeping track of EoRs and reconciling them against AFs supported on the 
session.

Yet another option would be to introduce a BMP-specific “end of initial BMP 
convergence” message that does what the current text suggests — a single 
message to say “done". That one smells the best to me, at the moment. It’s also 
the most intrusive.

Speaking as someone who soaks in how some customers use BMP, the per-AFI/SAFI 
end of rib is a feature rather than a bug.

BMP already serves to push the firehose of a router down a drinking straw.  
Being able to tell you're done with one address family is helpful to let some 
things come to convergence rather than waiting on everything.

The other headache of the single "I'm done" bit is the consequence on trying to 
get all of the per-AFI/SAFI queues to be done at the same time.  For example:
IPv4 unicast is done, no EoR is sent.
IPv6 unicast starts doing its work.
IPv4 unicast has more churn go through
IPv6 unicast is done, no EoR is sent.
System needs to go back to trying to get IPv4 unicast done to send EoR.  Pray 
that nothing else changes...

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[John Scudder]

(I moved idr to bcc, this is a grow doc, so let’s continue the conversation 
just on grow@ietf.org)

Hi All,

I agree this is a bug. Thanks, Vincent, for pointing it out. I think it should 
be fixed. Unfortunately (well, from the point of view of fixing it with an 
erratum anyway), there are several possible fixes and none of them is obviously 
the right one. One fix would be to completely remove this text:

  when End-of-RIB has been sent for each monitored peer, the
  initial table dump has completed.  (A monitoring station that only
  wants to gather a table dump could close the connection once it has
  gathered an End-of-RIB or Peer Down message corresponding to each
  Peer Up message.)

That would eliminate any specified way to know that initial convergence had 
completed, though. Implementations could still do it, but as a heuristic, not 
part of the spec. That doesn’t seem ideal to me. Another option would be to 
revise it to be consistent with practice, as in

  when End-of-RIB has been sent
  for each address family supported by
  each monitored peer, the
  initial table dump has completed.  (A monitoring station that only
  wants to gather a table dump could close the connection once it has
  gathered
  a corresponding set of End-of-RIB messages,
  or Peer Down message, corresponding to each
  Peer Up message.)

That’s cleaner but now the monitoring station has to go to the (minor?) trouble 
of keeping track of EoRs and reconciling them against AFs supported on the 
session. 

Yet another option would be to introduce a BMP-specific “end of initial BMP 
convergence” message that does what the current text suggests — a single 
message to say “done". That one smells the best to me, at the moment. It’s also 
the most intrusive.

If someone in the GROW WG has the stomach to take this forward, it seems to me 
that the best option would be to write and progress either a small draft fixing 
the bug (with one of the approaches above, or something else), or a full 
rfc7885bis. 

As far as an erratum goes, there’s no clean way to do it :-( since it’s not a 
bug with a single, straightforward fix. I think what I’m going to do is open an 
erratum describing the bug, without supplying any proposed “corrected text”, 
and with the full discussion of the options in the comment part. Warren then 
gets the fun of deciding if it should be verified as “hold for document 
update”, or what. 

Thanks,

—John

> On Sep 12, 2022, at 4:36 PM, Jeffrey Haas  wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> +grow, where BMP is standardized.
> 
> On Sun, Sep 11, 2022 at 09:45:29PM +0200, Vincent Bernat wrote:
>> Hey!
>> 
>> In 3.3:
>> 
>>   Once it has sent all the
>>   routes for a given peer, it MUST send an End-of-RIB message for that
>>   peer; when End-of-RIB has been sent for each monitored peer, the
>>   initial table dump has completed.  (A monitoring station that only
>>   wants to gather a table dump could close the connection once it has
>>   gathered an End-of-RIB or Peer Down message corresponding to each
>>   Peer Up message.)
>> 
>> The wording looks like the EoR is sent once per peer. However, an
>> EoR is AFI/SAFI-dependent. Therefore, it is unclear if any EoR
>> should signal the end of the initial table dump or if one EoR per
>> family is needed.
>> 
>> Looking at JunOS implementation, I see one EoR per family.
> 
> It is indeed per family in Juniper's implementation for exactly the reasons
> you mention.
> 
> If the authors agree that was the intent, it's minimally worth an RFC Errata
> covering the point.
> 
> -- Jeff
> 
> ___
> Idr mailing list
> i...@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A1ynY7YxND7J2FALzcYL8NWW6JRfMb91Tg-IgAuiyauDAcJR8UdiGL2icrHSzPj5CGrlz9LWGg$

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

[GROW] John Scudder's No Objection on draft-ietf-grow-bmp-local-rib-10: (with COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-grow-bmp-local-rib-10: No Objection

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/



--
COMMENT:
--

I agree with Alvaro’s comments. Some additional of my own:

1. I appreciate that section 1.1, "Alternative Method to Monitor Loc-RIB” was
necessary to guide WG discussion (not to mention as a way of illustrating the
problem to shortsighted authors of the base specification) but in the RFC, it
will be clutter for the implementor to skip over. IMO it would be kind of you
to move it to an appendix (or even remove it entirely, if you wish).

2. "BGP Instance: refers to an instance of an instance of BGP-4”. Did you mean
the repetition of “instance of”? Or is this an instance of the

Paris in the
the spring

problem? (I assume it is.)

3. In this definition:

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

The MUST seems inappropriate, unless you are imposing a new requirement — and
if so, what are you imposing the requirement on? The concept of a “Post-Policy
Adj-RIB-Out” (which implies the existence of a Pre-Policy Adj-RIB-Out”, as you
also define) doesn’t even exist in RFC 4271 — the Adj-RIB-Out is post-policy by
definition.

If you were to remove section 1.1, you could also remove the definitions of
Adj-RIB-Out, and this whole problem would go away as if by magic. :-)

4. Section 4.1:

   A new peer type is defined for Loc-RIB to distinguish that it
   represents Loc-RIB with or without RD and local instances.

"Distinguish whether”?

5. Section 4.2:

   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.

Given that you aren’t bumping the version number or otherwise signaling that
this spec is in use, how is the collector expected to know this? A priori by
configuration? It seems as though a prudent collector implementation would
still have to support the RFC 7854 encoding as well. At first glance that seems
OK — the collector could interpret the L-bit and also the Loc-RIB Instance Peer
type. It would be nice to have some words about this.

Having written the above, I think the text I’ve quoted, per se, is fine — you
can mandate that the new encoding always be used. (And too bad for old
collectors that don’t understand the format, I guess.)

6. Section 5, nit:

   other protocols into BGP or otherwise locally originated (ie.
   aggregate routes).

If you mean “for example” it’s “e.g.” (but it’s clearer IMO to write “for
example”). If you mean “in other words”, it’s “i.e.” (with two periods, but
it’s clearer IMO to write “in other words”).

7. Section 5.1, nit:

   All peer messages that include a per-peer header section 4.2 of
   [RFC7854] MUST use the following values:

The way this text has rendered, the reference needs parentheses around it. Same
for this one:

   *  Peer BGP ID: Set to the BGP instance global or RD (e.g.  VRF)
  specific router-id section 1.1 of [RFC7854].

8. Section 5.2.1:

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

I take it the empty string isn’t allowed, by design.

9. Section 5.2.1:

   Multiple TLVs of the same type can be repeated as part of the same
   message, for example to convey a filtered view of a VRF.  A BMP
   receiver should append multiple TLVs of the same type to a set in
   order to support alternate or additional names for the same peer.  If
   multiple strings are included, their ordering MUST be preserved when
   they are reported.

The way this is written, it’s not clear if you’re modifying the base spec to
permit multiple TLVs of the same arbitrary type, informatively stating a
property of the base spec, or saying this is how the VRF/Table Name TLV is to
be handled. Looking back over RFC 7854, I think it is probably the latter — you
want to say only how the VRF/Table Name TLV is used. In that case, I think you
should change “same type” to “this type”. The indent of the paragraph seems
wrong, too — shouldn’t it be part of the bullet text?

Al

Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

[John Scudder]

(As an individual contributor and co-author.)

Thanks for extending this, Sue. Maybe it will help the WG to have a reminder 
about what this document does. 

It’s a revision of RFC 8203. First, here is the rfcdiff vs. RFC 8203: 
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8203&url2=draft-ietf-idr-rfc8203bis
It is quite short, especially when you skip over the boilerplate and "RFC 
EDITOR: REMOVE BEFORE PUBLICATION” sections. 

The sole normative change vs. 8203 is the deletion of one sentence:

OLD:
   Length:  this 8-bit field represents the length of the Shutdown
  Communication field in octets.  The length value MUST range from 0
  to 128 inclusive.  When the length value is zero, no Shutdown
  Communication field follows.
NEW:
   Length:  this 8-bit field represents the length of the Shutdown
  Communication field in octets.  When the length value is zero, no
  Shutdown Communication field follows.

The reason for this change is summarized in in Appendix B:

   Feedback from operators based in regions which predominantly use
   multibyte character sets, showed that messages similar in meaning to
   what can be send in other languages in using single-byte encoding,
   failed to fit within the Length constraints as specified by
   [RFC8203].  For example, the phrase: 'Planned work to add switch to
   stack.  Completion time - 30 minutes' has length 65 bytes.  Its
   translation in Russian
   'Плановые
   работы по д

   86;бавлению к&#
   1086;ммутатора&
   #1074;
   стек.Время 

   79;авершения -
   30минут' (See PDF for non-ASCII
   character string) has length 139 bytes.

Now you do not need to actually go read the draft in order to know everything 
you need to respond to the WGLC. :-)

Thanks,

—John


> On Jul 25, 2019, at 5:25 PM, Susan Hares  wrote:
> 
> Greetings IDR: 
>  
> The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received 
> only 2 comments.  Since this is a draft that updates an operationally needed 
> feature,  I am extending the WG LC until 8/6/2019.  
>  
> If you believe this draft is ready for publication, please respond to this WG 
> LC. 
>  
> Sue Hares 
>  
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
> Sent: Tuesday, July 9, 2019 9:13 AM
> To: 'idr wg'
> Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication 
> (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)
>  
> This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from 
> July 9, 2019 to July 23, 2019. . 
>  
> Please consider if you believe this revision of RFC8203 (Administrative 
> Shutdown)
> a)  Will benefit operational networks,
> b)  is technically complete, and 
> c)   ready for publication. 
>  
> In your comments, please indicate whether you “support” or “do not support” 
> its publication. 
>  
> This draft contains IPR notice that causes “IPR warnings”.   The authors 
> believe that this text is automatically generated by the IETF tools and the 
> warning is not appropriate.   
>  
> As the shepherd, I am  investigating this issue.   If you have specific 
> knowledge on this issue, you may send it to the list or to me directly. 
>  
> Cheerily, Susan Hares 
>  
___
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)

[John Scudder]

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, Christopher Morrow 
mailto:christopher.mor...@gmail.com>> wrote:

Tim did this 6/7/2019 (june 7)
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbmp-2Dlocal-2Drib-2D04&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=tMgY5YxF35lgXApQPUcggCTGaqI3b-99tYFMOfOH_O0&s=mEXLZvGL2jAluO27b1erwEOrR4FZTDWZRy-_z09wR4A&e=

huazzah! moving forward I think is ok now?

-chris
co-chairy

On Sat, Jun 1, 2019 at 5:23 AM Tim Evens (tievens) 
mailto:tiev...@cisco.com>> wrote:

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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_grow_wA3Nkz2lw6obTH9fF1X2Mkm4INM&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=tMgY5YxF35lgXApQPUcggCTGaqI3b-99tYFMOfOH_O0&s=7404YXkfnlK85bQoxYR6zfNagba4I3sdH2CqnE2g_W8&e=
 ) using the solution Paolo and I agreed later 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_grow_t6LKhCLc-2DE-5FawiVHowB4WDnMSps&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=tMgY5YxF35lgXApQPUcggCTGaqI3b-99tYFMOfOH_O0&s=axhG8-NAco1sysXpwqBXpbwIwg-qvMc6UUqVp-Ib2dA&e=
 ).

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<mailto:GROW@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=tMgY5YxF35lgXApQPUcggCTGaqI3b-99tYFMOfOH_O0&s=JJca_ZIsMAwCblZYuFntYx0RArdkIN94qEREzsu6yjI&e=

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=tMgY5YxF35lgXApQPUcggCTGaqI3b-99tYFMOfOH_O0&s=JJca_ZIsMAwCblZYuFntYx0RArdkIN94qEREzsu6yjI&e=

___
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

[John Scudder]

On Jun 13, 2019, at 1:18 PM, Randy Bush mailto:ra...@psg.com>> 
wrote:

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.

just ref 7854 sec 4.2 Timestamp

Only problem just referencing it is “timestamp” in 7854 isn’t quite the same as 
what Mukul suggests. Here’s 7854:


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


Only the first clause differs, but it’s an important clause. It would be 
equally correct to say something like “Timestamp: this is the same as the 
timestamp defined in RFC 7854 section 4.2, except the time it specifies is when 
the encapsulated routes were advertised (one may also think of this as the time 
when they were installed in the Adj-RIB-Out).”

I don’t have a strong preference between the two. One normally wants to avoid 
cut-and-paste, but in this case optimizing the text saves a grand total of 9 
words and makes the reader look in two places. Potayyyto, pottto.

—John
___
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

[John Scudder]

This also makes sense to me.

Thanks,

—John

On Jun 13, 2019, at 11:16 AM, Mukul Srivastava 
mailto:m...@juniper.net>> 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.

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

[John Scudder]

This makes sense to me, thanks.

—John

On Jun 13, 2019, at 9: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] I-D Action: draft-ietf-grow-bmp-registries-change-01.txt

[John Scudder]

On Jun 3, 2019, at 4:47 PM, 
internet-dra...@ietf.org<mailto: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   : Revision to Registration Procedures for Multiple BMP 
Registries
   Author  : John Scudder
Filename: draft-ietf-grow-bmp-registries-change-01.txt
Pages   : 3
Date: 2019-06-03

FYI this is just a version bump to prevent the draft from expiring on the day 
the WGLC ends.

—John

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

Re: [GROW] [Editorial Errata Reported] RFC7854 (5736)

[John Scudder]

For what it’s worth I’m fine with this erratum. I never liked that ruler, I 
agree the proposed version is less confusing. Not sure if it should be 
categorized as “Verified” or “Hold for Update”, no skin off me either way.

—John

> On May 23, 2019, at 4:14 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7854,
> "BGP Monitoring Protocol (BMP)".
> 
> --
> You may review the report below and at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_errata_eid5736&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=DgC438Xn2I0aj_fAWhRDAatmFbk1Q49ICSV-jSNxAck&s=_s2BABLq_pyJlsg8Zj_FHgZ0-1Nfpn1lJomW2AXTXvU&e=
> 
> --
> Type: Editorial
> Reported by: Mohamed Boucadair 
> 
> Section: 4.2
> 
> Original Text
> -
>  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) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Corrected Text
> --
>  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) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Notes
> -
> The OLD figure may be misinterpreted as if there are unused bits between the 
> "Peer Flags" and "Peer Distinguisher".
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7854 (draft-ietf-grow-bmp-17)
> --
> Title   : BGP Monitoring Protocol (BMP)
> Publication Date: June 2016
> Author(s)   : J. Scudder, Ed., R. Fernando, S. Stuart
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

___
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)

[John Scudder]

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] Prefix limit ORF

[John Scudder]

Apropos Job’s talk just now —

draft-keyur-idr-bgp-prefix-limit-orf-03
https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf-03

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

[GROW] Proposing draft-scudder-grow-bmp-peer-up as WG doc [was: Fwd: Separating the BMP Initiation and Peer Up namespaces]

[John Scudder]

Hi All,

This is the draft I just spoke about in our meeting.

Thanks,

—John

Begin forwarded message:

From: John Scudder mailto:j...@juniper.net>>
Subject: Re: [GROW] Separating the BMP Initiation and Peer Up namespaces
Date: February 7, 2019 at 9:07:43 PM GMT+1
To: Paolo Lucente mailto:pa...@ntt.net>>, 
"grow-cha...@ietf.org<mailto:grow-cha...@ietf.org>" 
mailto:grow-cha...@ietf.org>>
Cc: "grow@ietf.org<mailto:grow@ietf.org>" mailto:grow@ietf.org>>

Thanks, Paolo.

GROW chairs, I'd like to propose this as a WG item.

Regards,

--John

On Jan 23, 2019, at 9:05 AM, Paolo Lucente 
mailto:pa...@ntt.net>> 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 get there.

Given the above, I do support this.

Paolo

On 15 Dec 2018, at 00:41, John Scudder 
mailto:j...@juniper.net>> wrote:

Hi All,

As I mentioned in the other thread, I think it was a mistake for Peer Up and 
Initiation to share a namespace in RFC 7854. The fact that it's difficult to 
get the text right in draft-ietf-grow-bmp-local-rib demonstrates this.

My suggestion is that we separate the namespaces. I've written and submitted a 
short draft to do it, draft-scudder-grow-bmp-peer-up-00.txt [1]. It seemed the 
most expedient way to describe the suggested approach. If the WG likes the 
idea, we can adopt it, or if the WG wants to fix it a different way, let's 
discuss.

An alternate solution would be to embrace the Information TLV as a namespace 
that's shared between multiple messages (the implication in 
draft-ietf-grow-bmp-local-rib that the Information TLV could be included in 
Peer Down suggests that's what the authors imagine would happen). I don't 
prefer this because it requires enumeration of exceptions ("foo Information 
type only applies when carried in such-and-such BMP message type..."). 
Independent namespaces ends up being a little wordier but less error-prone, IMO.

Regards,

--John

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dscudder-2Dgrow-2Dbmp-2Dpeer-2Dup-2D00.txt&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=LPelXJjYk_g20JRvzjj5Z57yrTysbVdFVF5HOfqclBw&s=x-wlUF_VuHZSdkJHN-UPkD3LjBIY6hhUEzRNOCKa7Wk&e=
___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=LPelXJjYk_g20JRvzjj5Z57yrTysbVdFVF5HOfqclBw&s=zujlTq7Z94sjyfCLfICAHYyEwZK4r3Si0WsJuR3maP8&e=

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=_d-zJpan1WHlv7NQSYb-arvxgHLrMy-yqHHMxtWKJtk&s=DTFEGoWwcbp0URVg38o4UhWSCd_cqPGtaTwv8D37Fv4&e=

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

Re: [GROW] Separating the BMP Initiation and Peer Up namespaces

[John Scudder]

Thanks, Paolo.

GROW chairs, I'd like to propose this as a WG item.

Regards,

--John

On Jan 23, 2019, at 9:05 AM, Paolo Lucente 
mailto:pa...@ntt.net>> 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 get there.

Given the above, I do support this.

Paolo

On 15 Dec 2018, at 00:41, John Scudder 
mailto:j...@juniper.net>> wrote:

Hi All,

As I mentioned in the other thread, I think it was a mistake for Peer Up and 
Initiation to share a namespace in RFC 7854. The fact that it's difficult to 
get the text right in draft-ietf-grow-bmp-local-rib demonstrates this.

My suggestion is that we separate the namespaces. I've written and submitted a 
short draft to do it, draft-scudder-grow-bmp-peer-up-00.txt [1]. It seemed the 
most expedient way to describe the suggested approach. If the WG likes the 
idea, we can adopt it, or if the WG wants to fix it a different way, let's 
discuss.

An alternate solution would be to embrace the Information TLV as a namespace 
that's shared between multiple messages (the implication in 
draft-ietf-grow-bmp-local-rib that the Information TLV could be included in 
Peer Down suggests that's what the authors imagine would happen). I don't 
prefer this because it requires enumeration of exceptions ("foo Information 
type only applies when carried in such-and-such BMP message type..."). 
Independent namespaces ends up being a little wordier but less error-prone, IMO.

Regards,

--John

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dscudder-2Dgrow-2Dbmp-2Dpeer-2Dup-2D00.txt&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=LPelXJjYk_g20JRvzjj5Z57yrTysbVdFVF5HOfqclBw&s=x-wlUF_VuHZSdkJHN-UPkD3LjBIY6hhUEzRNOCKa7Wk&e=
___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=LPelXJjYk_g20JRvzjj5Z57yrTysbVdFVF5HOfqclBw&s=zujlTq7Z94sjyfCLfICAHYyEwZK4r3Si0WsJuR3maP8&e=

___
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)

[John Scudder]

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 get there.

This is clearly an idea all right-thinking people will support and the reason 
we don't see more "+1" replies is because everyone assumes it obviously a good 
idea. :-) 

>> On 15 Dec 2018, at 00:40, John Scudder  wrote:
>> 
>> [ .. ]
>> 
>> One fix, I think the more expedient one, would be to request a new reason 
>> code ("TBD3"), whose format includes both the content carried in reason 2, 
>> and a VRF/Table Name. Then if you want to send the table name, you use the 
>> new reason code.
>> 
>> An alternate fix, somewhat more involved but possibly useful in the long 
>> run, would be to update RFC 7854 to permit Peer Down messages to carry 
>> additional data beyond the reason code and its own associated data, and then 
>> to define the format of that data. Probably the additional data would be 
>> TLVized. It would obviously need to have a registry created for it.
> 
> If i get you correctly, updating RFC7854 is what would get to the ideal 
> scenario above. I feel, for the reasons you explain, this is the kind of 
> change that would require a version bump in order to make it clean.

While there are ways to do it without a version bump, I agree with you that 
bumping the version keeps it clean.

> Perhaps a longer term plan, where we do also tackle the subject of TLV & 
> Route Monitor message?

As in Henk's earlier (and still not dead!) proposal?

> 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?

Thanks,

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

Re: [GROW] Separating the BMP Initiation and Peer Up namespaces

[John Scudder]

Also bumping this one.

--John

> On Dec 14, 2018, at 6:41 PM, John Scudder  wrote:
> 
> Hi All,
> 
> As I mentioned in the other thread, I think it was a mistake for Peer Up and 
> Initiation to share a namespace in RFC 7854. The fact that it's difficult to 
> get the text right in draft-ietf-grow-bmp-local-rib demonstrates this.
> 
> My suggestion is that we separate the namespaces. I've written and submitted 
> a short draft to do it, draft-scudder-grow-bmp-peer-up-00.txt [1]. It seemed 
> the most expedient way to describe the suggested approach. If the WG likes 
> the idea, we can adopt it, or if the WG wants to fix it a different way, 
> let's discuss.
> 
> An alternate solution would be to embrace the Information TLV as a namespace 
> that's shared between multiple messages (the implication in 
> draft-ietf-grow-bmp-local-rib that the Information TLV could be included in 
> Peer Down suggests that's what the authors imagine would happen). I don't 
> prefer this because it requires enumeration of exceptions ("foo Information 
> type only applies when carried in such-and-such BMP message type..."). 
> Independent namespaces ends up being a little wordier but less error-prone, 
> IMO.
> 
> Regards,
> 
> --John
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dscudder-2Dgrow-2Dbmp-2Dpeer-2Dup-2D00.txt&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=D7IqMWtdausMkdGGw6TfUPIh8G7-jy-nCqGt8a4mysw&s=KiqiStww6xXZe8HN7VoUO2WcW049EmV0bIpjjeFkvPg&e=
> ___
> GROW mailing list
> GROW@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=D7IqMWtdausMkdGGw6TfUPIh8G7-jy-nCqGt8a4mysw&s=7y0yLjzXTHGgjIubMs5n5pu9fspj-FApMH7efiVImRU&e=

___
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)

[John Scudder]

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:
>> 
>> 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 more involved but possibly useful in the long 
>> run, would be to update RFC 7854 to permit Peer Down messages to carry 
>> additional data beyond the reason code and its own associated data, and then 
>> to define the format of that data. Probably the additional data would be 
>> TLVized. It would obviously need to have a registry created for it. 
> 
> It occurs to me that the main reason I can think of NOT to adopt this option 
> would be that existing BMP server implementations might choke on new-style 
> PDUs as described above, since they are illegal per the base spec. The fact 
> RFC 7854 is underspecified as to what if any error checking and enforcement 
> should be done, makes this maybe somewhat less of a concern (there's no 
> mandated "you must reset the session upon protocol errors") but there's still 
> no guarantee a server wouldn't experience an internal error.
> 
> Whether the WG thinks this is a genuine concern or not, is a matter for 
> discussion. Reasons to think it's not a big deal include,
> 
> - I would hope most server implementations would be robust to this kind of 
> malformation, but I don't actually know, I can just apply the "well that's 
> how I would have done it" heuristic, which a pretty weak one.
> - Presumably the extra (nonconformant to RFC 7854) TLV would only be emitted 
> when Loc-RIB functionality was configured, and presumably Loc-RIB 
> functionality would only be configured if the server on the other end 
> supported consuming it (otherwise why bother), Q.E.D. only a compliant server 
> would see the new TLV.
> 
> Reasons to think it is a big deal include reflexive conservatism, which is 
> not always a bad thing in networking standards. 
> 
> By contrast, the other option I offered, allocating a new Reason code that 
> includes a string field, is guaranteed to be backward-compatible with 
> compliant implementations. And by "guaranteed" I mean "probably" since I see 
> RFC 7854 section 4.9 doesn't explicitly say "you have to be tolerant of 
> unrecognized Reason codes", however, I think this is a pretty good bet. It's 
> certainly the more conservative option.
> 
> $0.02,
> 
> --John
> ___
> GROW mailing list
> GROW@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=utvYcoebXr3QSPs9cdM9P7Cv6pScVERGzE35h9RAf40&s=RVl2YX_bCdXH2LUx2OZdc2Ys8WBT_vt3Mcfe3clvKtU&e=

___
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)

[John Scudder]

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 more involved but possibly useful in the long run, 
> would be to update RFC 7854 to permit Peer Down messages to carry additional 
> data beyond the reason code and its own associated data, and then to define 
> the format of that data. Probably the additional data would be TLVized. It 
> would obviously need to have a registry created for it. 

It occurs to me that the main reason I can think of NOT to adopt this option 
would be that existing BMP server implementations might choke on new-style PDUs 
as described above, since they are illegal per the base spec. The fact RFC 7854 
is underspecified as to what if any error checking and enforcement should be 
done, makes this maybe somewhat less of a concern (there's no mandated "you 
must reset the session upon protocol errors") but there's still no guarantee a 
server wouldn't experience an internal error.

Whether the WG thinks this is a genuine concern or not, is a matter for 
discussion. Reasons to think it's not a big deal include,

- I would hope most server implementations would be robust to this kind of 
malformation, but I don't actually know, I can just apply the "well that's how 
I would have done it" heuristic, which a pretty weak one.
- Presumably the extra (nonconformant to RFC 7854) TLV would only be emitted 
when Loc-RIB functionality was configured, and presumably Loc-RIB functionality 
would only be configured if the server on the other end supported consuming it 
(otherwise why bother), Q.E.D. only a compliant server would see the new TLV.

Reasons to think it is a big deal include reflexive conservatism, which is not 
always a bad thing in networking standards. 

By contrast, the other option I offered, allocating a new Reason code that 
includes a string field, is guaranteed to be backward-compatible with compliant 
implementations. And by "guaranteed" I mean "probably" since I see RFC 7854 
section 4.9 doesn't explicitly say "you have to be tolerant of unrecognized 
Reason codes", however, I think this is a pretty good bet. It's certainly the 
more conservative option.

$0.02,

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

[GROW] Separating the BMP Initiation and Peer Up namespaces

[John Scudder]

Hi All,

As I mentioned in the other thread, I think it was a mistake for Peer Up and 
Initiation to share a namespace in RFC 7854. The fact that it's difficult to 
get the text right in draft-ietf-grow-bmp-local-rib demonstrates this.

My suggestion is that we separate the namespaces. I've written and submitted a 
short draft to do it, draft-scudder-grow-bmp-peer-up-00.txt [1]. It seemed the 
most expedient way to describe the suggested approach. If the WG likes the 
idea, we can adopt it, or if the WG wants to fix it a different way, let's 
discuss.

An alternate solution would be to embrace the Information TLV as a namespace 
that's shared between multiple messages (the implication in 
draft-ietf-grow-bmp-local-rib that the Information TLV could be included in 
Peer Down suggests that's what the authors imagine would happen). I don't 
prefer this because it requires enumeration of exceptions ("foo Information 
type only applies when carried in such-and-such BMP message type..."). 
Independent namespaces ends up being a little wordier but less error-prone, IMO.

Regards,

--John

[1] https://www.ietf.org/id/draft-scudder-grow-bmp-peer-up-00.txt
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Separating the BMP Initiation and Peer Up namespaces

[John Scudder]

Hi All,

As I mentioned in the other thread, I think it was a mistake for Peer Up and 
Initiation to share a namespace in RFC 7854. The fact that it's difficult to 
get the text right in draft-ietf-grow-bmp-local-rib demonstrates this.

My suggestion is that we separate the namespaces. I've written and submitted a 
short draft to do it, draft-scudder-grow-bmp-peer-up-00.txt [1]. It seemed the 
most expedient way to describe the suggested approach. If the WG likes the 
idea, we can adopt it, or if the WG wants to fix it a different way, let's 
discuss.

An alternate solution would be to embrace the Information TLV as a namespace 
that's shared between multiple messages (the implication in 
draft-ietf-grow-bmp-local-rib that the Information TLV could be included in 
Peer Down suggests that's what the authors imagine would happen). I don't 
prefer this because it requires enumeration of exceptions ("foo Information 
type only applies when carried in such-and-such BMP message type..."). 
Independent namespaces ends up being a little wordier but less error-prone, IMO.

Regards,

--John

[1] https://www.ietf.org/id/draft-scudder-grow-bmp-peer-up-00.txt
___
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)

[John Scudder]

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 mail thread to discuss 
the problem and proposed fix in more detail. (Not to keep anyone in suspense, I 
think it was a mistake to have the Initiation and Peer Up messages share a 
namespace. More broadly I think the authors, ahem, of 7854 didn't drink enough 
of the TLV koolade before finalizing it.)

Issue 1. draft-ietf-grow-bmp-local-rib says:


   Peer down notification SHOULD follow the section 4.9 [RFC7854] reason
   2.

   The VRF/Table Name informational TLV SHOULD be included if it was in
   the Peer UP.


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:


   o  Reason 2: The local system closed the session.  No notification
  message was sent.  Following the reason code is a 2-byte field
  containing the code corresponding to the Finite State Machine
  (FSM) Event that caused the system to close the session (see
  Section 8.1 of [RFC4271]).  Two bytes both set to 0 are used to
  indicate that no relevant Event code is defined.


One fix, I think the more expedient one, would be to request a new reason code 
("TBD3"), whose format includes both the content carried in reason 2, and a 
VRF/Table Name. Then if you want to send the table name, you use the new reason 
code.

An alternate fix, somewhat more involved but possibly useful in the long run, 
would be to update RFC 7854 to permit Peer Down messages to carry additional 
data beyond the reason code and its own associated data, and then to define the 
format of that data. Probably the additional data would be TLVized. It would 
obviously need to have a registry created for it.

By the way, shouldn't those "SHOULDs" be "MUSTs"? If not MUST, under what 
circumstances MAY they be omitted?

Issue 2. draft-ietf-grow-bmp-local-rib says:


   The following peer UP information TLV types are added:

   o  Type = TBD2: VRF/Table Name.  The Information field contains an
  ASCII 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 VRF/Table Name TLV is optionally included.  For consistency,
  it is RECOMMENDED that the VRF/Table Name always be included.  The
  default value of "global" SHOULD be used for the default Loc-RIB
  instance with a zero-filled distinguisher.  If the TLV is
  included, then it SHOULD also be included in the Peer Down
  notification.


Nit1, "types are added" should be "type is added".

Nit2, I'm not crazy about the definition of string here, and ASCII should 
almost certainly be UTF-8. I will offer a replacement definition in the other 
thread I'll start.

Nit3, all those SHOULDs. Can't they be MUSTs? If not, can you give the reader a 
hint of why not?

The real problem (this is the one that came from RFC 7854): though the text 
says "peer UP information TLV types are added", there is no such thing as the 
peer UP information TLV! We could fix this by adding the type to the 
Information TLV, which in RFC 7854 is shared by Initiation and Peer Up. However 
I think it is a cleaner fix to separate the namespaces, one for Initiation and 
one for Peer Up. Once that's done (and it should be easy unless there's 
controversy), just allocate the TLV out of the (to be created) Peer Up Message 
TLVs registry. (This is what I'm starting a new thread to discuss.)

Thanks,

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

Re: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 2018.09.25-2018.10.09

[John Scudder]

I've uploaded the WG draft for your approval. I removed one unused informative 
reference (probably a cut-and-paste error). The draft is otherwise the same as 
before.

I am not aware of any relevant IPR.

I would also like to suggest a WGLC as soon as you deem it appropriate.

Thanks,

--John

> On Oct 9, 2018, at 2:56 AM, Job Snijders  wrote:
> 
> Dear all,
> 
> Thank you all for your feedback. Sufficient support was shown to have
> GROW adopt this Internet-Draft as working group item.
> 
> John, as author, can you please resubmit with filename
> draft-ietf-grow-bmp-registries-change and state whether you are aware of
> any IPR?
> 
> Kind regards,
> 
> Job
> 
> On Tue, Sep 25, 2018 at 04:04:30PM +, Job Snijders wrote:
>> Dear working group,
>> 
>> Feedback from the working group seems to indicate a preference to follow
>> regular procedures. So, we will do so!
>> 
>> The author of draft-scudder-grow-bmp-registries-change [1] requested the
>> chairs to consider issuing a call for working group adoption. Here is
>> the abstract:
>> 
>>"This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>>making a change to the registration procedures for several
>>registries. Specifically, any BMP registry with a range of
>>32768-65530 designated "Specification Required" has that range re-
>>designated as "First Come First Served".
>> 
>>[1]: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dscudder-2Dgrow-2Dbmp-2Dregistries-2Dchange-2D00.txt&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=U7cydE7qa0P2FsL9WHsJUvUviFr_EIw3Sqe2lR3VWXc&s=h_dnR6XNzNF2jHnjnZW0jrIA_xy11PVIpCgDHCxnJlY&e=
>> 
>> Please take a moment to read and evaluate the document and let the
>> working group know whether you'd like to continue work on this document
>> as working group or not.
>> 
>> We'll close the call on 2018-10-09
>> 
>> Kind regards,
>> 
>> Job
>> 

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

Re: [GROW] draft-scudder-idr-capabilities-registry-change-02 - has been adopted

[John Scudder]

Once I've issued -01 I'd be comfortable with WGLC. I do want to allow enough 
time for any other undocumented code points to be added, but that can also 
happen as part of WGLC.

I am not aware of any IPR related to this draft.

Thanks,

--John

On Oct 3, 2018, at 10:26 AM, Susan Hares 
mailto:sha...@ndzh.com>> wrote:

Greetings:

The WG has adopted draft-scudder-idr-capabilities-registry-change-02.txt.
The authors should submit this as 
draft-ietf-idr-capabilities-registry-change-00.txt.

Are the authors ready for WG last call on this document?

In preparation for a WG LC, the authors should indicate if they know of any IPR 
regarding the draft.   (My apologies for the repeated IPR call but I do not 
want to miss a process step with this draft.  I would like this document go as 
swiftly as the IDR/Grow WG desires).

Susan Hares
___
GROW mailing list
GROW@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=hCL8mraR3kh-svxIYCM_9kBFzPYCUIDtED7QmiPBfIk&s=oC1NtlKpyjHEuzAa_5Vlm2cTWFhBGu-VSQhxDKTJido&e=

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

Re: [GROW] [Idr] draft-scudder-idr-capabilities-registry-change-02 - has been adopted

[John Scudder]

Thanks, Martin. Unless there are objections I'll reflect these in -01. Reminder 
to other implementors --

   Finally, we invite implementors who have used values in the range
   128-255 to contribute to this draft, so that the values can be
   included in the registry.

Thanks,

--John

On Nov 7, 2018, at 12:38 AM, Martin Djernaes 
mailto:mdjern...@juniper.net>> wrote:

Hi

I want to confess on the behalf of Juniper that we have "old" capabilities for 
refresh on 128 and ORF on 130 so they hopefully both will be reserved and we 
will not see trouble from implementations.

Martin



From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Wednesday, October 3, 2018 16:27
To: i...@ietf.org
Cc: grow@ietf.org
Subject: [Idr] draft-scudder-idr-capabilities-registry-change-02 - has been 
adopted

Greetings:

The WG has adopted draft-scudder-idr-capabilities-registry-change-02.txt.
The authors should submit this as 
draft-ietf-idr-capabilities-registry-change-00.txt.

Are the authors ready for WG last call on this document?

In preparation for a WG LC, the authors should indicate if they know of any IPR 
regarding the draft.   (My apologies for the repeated IPR call but I do not 
want to miss a process step with this draft.  I would like this document go as 
swiftly as the IDR/Grow WG desires).

Susan Hares
___
GROW mailing list
GROW@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=DpD2Y53P0Is4IraxkJ4JirEGE3eyS8S2JadxLHnj8JU&s=CMG0TQrPDBT0bz0PTT5ND8_Qeuf2HPBOEUX4vIWdOE4&e=

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

[GROW] Making BMP registries FCFS

[John Scudder]

Hi All,

A while ago we talked about this. I finally wrote a draft for it, 
https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt:

Abstract

   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
   making a change to the registration procedures for several
   registries.  Specifically, any BMP registry with a range of
   32768-65530 designated "Specification Required" has that range re-
   designated as "First Come First Served".

It's super short, 3 pages including all the boilerplate. I'd like to propose it 
as a WG item (and ideally, move it quickly to WGLC).

Thanks,

--John

P.S.: I'm one of the designated experts for those registries ("Specification 
Required" requires designated experts who review all requests). So I have the 
ulterior motive of trying to get rid of work. :-)
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7854 (4830)

[John Scudder]

This looks right to me. Suggest moving it to "Verified".

Thanks,

--John

> On Oct 12, 2016, at 3:27 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7854,
> "BGP Monitoring Protocol (BMP)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7854&eid=4830
> 
> --
> Type: Technical
> Reported by: Suhas Anand 
> 
> Section: 4.9
> 
> Original Text
> -
> Peer Down Notification
> 
>   This message is used to indicate that a peering session was
>   terminated.
> 
>  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
> +-+-+-+-+-+-+-+-+
> |Reason |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Data (present if Reason = 1, 2 or 3)   |
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Corrected Text
> --
> Peer Down Notification
> 
>   This message is used to indicate that a peering session was
>   terminated. Following the common BMP header and per-peer header is 
>   the following:
> 
>  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
> +-+-+-+-+-+-+-+-+
> |Reason |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Data (present if Reason = 1, 2 or 3)   |
> ~   ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Notes
> -
> What: 
> 
> For Peer Down Notification: To the programmer implementing the RFC, it is not 
> clear if the Peer Down message consists of per peer header
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7854 (draft-ietf-grow-bmp-17)
> --
> Title   : BGP Monitoring Protocol (BMP)
> Publication Date: June 2016
> Author(s)   : J. Scudder, Ed., R. Fernando, S. Stuart
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [GROW] [Editorial Errata Reported] RFC7854 (4722)

[John Scudder]

+grow-ads

I notice this erratum Is still sitting in "Reported", IMO it can be moved to 
"Hold for Document Update".

--John

> On Jun 28, 2016, at 10:05 AM, John G. Scudder  wrote:
> 
> Yep. I suppose this is a "hold for document update"?
> 
> --John
> 
>> On Jun 28, 2016, at 9:35 AM, Christopher Morrow 
>> mailto:christopher.mor...@gmail.com>> wrote:
>> 
>> seems ok (to me) to expand stats -> statistics...
>> 
>> On Tue, Jun 28, 2016 at 8:45 AM, RFC Errata System 
>> mailto:rfc-edi...@rfc-editor.org>> wrote:
>> The following errata report has been submitted for RFC7854,
>> "BGP Monitoring Protocol (BMP)".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7854&eid=4722 
>> 
>> 
>> --
>> Type: Editorial
>> Reported by: Stéphane Bortzmeyer > >
>> 
>> Section: 3.1 4.8 7
>> 
>> Original Text
>> -
>> Stats Reports
>> 
>> Corrected Text
>> --
>> Statistics Reports
>> 
>> Notes
>> -
>> The message of type 1 is called "Statistics Report" in the IANA registry 
>> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xml#message-types
>>  
>> 
>>  (I used it as the reference) and in sections 4.1 and 10.1 but "Stats 
>> Report" in sections 3.1, 4.8 and 7.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC7854 (draft-ietf-grow-bmp-17)
>> --
>> Title   : BGP Monitoring Protocol (BMP)
>> Publication Date: June 2016
>> Author(s)   : J. Scudder, Ed., R. Fernando, S. Stuart
>> Category: PROPOSED STANDARD
>> Source  : Global Routing Operations
>> Area: Operations and Management
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> 
> 
> ___
> 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] Stephen Farrell's Discuss on draft-ietf-grow-bmp-16: (with DISCUSS and COMMENT)

[John Scudder]

On Dec 4, 2015, at 9:48 PM, Randy Bush  wrote:

>>   Where the security considerations outlined above are a concern, users
>>   of this protocol should use IPsec [RFC4303] in tunnel mode with
>>   preshared keys.
> 
> the classic wiggle from the 1990s.  and no one ever does it.  and at the
> using layer, you can not even detect if it is in place and abort if it
> is not.  #fail

I do not understand your point. Wasn't actually intended as a wiggle, but as an 
option that you can actually do with existing shipping code. Maybe we can 
discuss Monday. 

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

Re: [GROW] Alia Atlas' Yes on draft-ietf-grow-bmp-15: (with COMMENT)

[John Scudder]

On Oct 15, 2015, at 4:46 AM, Alia Atlas  wrote:
> 
> a) In Section 4.2, I see special casing for an "L3VPN Instance Peer". 
> Will the same thing be necessary for an EVPN peer?  Are there other
> future cases to be considered?

This was an interesting question, thanks. On reflection, "L3VPN Instance Peer" 
is a misnomer, it really means something more like "peers whose context is 
identified by an RD". Probably we should rename this field; I suggest "RD 
Instance Peer" and have stubbed this in. Since EVPN and other L3VPN variants 
are identified by RDs taken from a common namespace, they fit in. We may need 
to extend the Peer Types to accommodate peers that are neither "global 
instance" nor RD, see Rob Shakir's earlier comment. Really, you could think of 
the catenation of the Peer Type and Peer Distinguisher fields as comprising a 
unique identifier for the peer.

I think for this draft we should fix the name to clarify what the field really 
means, but not try to extend to other types of peers. That ought to be 
straightforward enough in an update document if needed.

> b) In Sec 4.4, for the type=0 String, it may be useful to specify that
> the language is unspecified and based on the configuration.  A similar
> description for the other information strings would be useful.  I'm sure
> that Barry could suggest better text.

Barry, since Alia volunteered your services :-) would you be willing to suggest 
some text, or OK this option?

OLD:
  *  Type = 0: String.  The Information field contains a free-form
 UTF-8 string whose length is given by the "Information Length"
 field.  The value is administratively assigned.  There is no
 requirement to terminate the string with a null (or any other
 particular) character -- the length field gives its
 termination.  If multiple strings are included, their ordering
 MUST be preserved when they are reported.
NEW:
  *  Type = 0: String.  The Information field contains a free-form
 UTF-8 string whose length is given by the "Information Length"
 field.  The value (including the language) is administratively 
assigned.  There is no
 requirement to terminate the string with a null (or any other
 particular) character -- the length field gives its
 termination.  If multiple strings are included, their ordering
 MUST be preserved when they are reported.

and

OLD:
  *  Type = 0: String.  The Information field contains a free-form
 UTF-8 string whose length is given by the "Information Length"
 field.  Inclusion of this TLV is optional.  It MAY be used to
 provide further detail for any of the defined reasons.
 Multiple String TLVs MAY be included in the message.
NEW:
  *  Type = 0: String.  The Information field contains a free-form
 UTF-8 string whose length is given by the "Information Length"
 field.  The language is unspecified and may be determined by the 
implementation and/or configuration.
 Inclusion of this TLV is optional.  It MAY be used to
 provide further detail for any of the defined reasons.
 Multiple String TLVs MAY be included in the message.

Thanks,

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

Re: [GROW] Kathleen Moriarty's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS)

[John Scudder]

On Oct 13, 2015, at 10:06 PM, Kathleen Moriarty 
 wrote:
> 
> It would be nice if there
> was an MTI for transport

I owe you a proper reply, but can you decode "MTI" for me please?

Thanks,

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

[GROW] Fwd: New Version Notification for draft-ietf-grow-bmp-09.txt

[John Scudder]

Hi Everyone,

Version -09 contains some minor editorial and stylistic changes and one 
substantive change (or rather, set of substantive changes) which is that for 
every IANA registry I created a small range near the end as "Experimental" and 
reserved the last value. Seemed like good practice.

I hope this is the final version and would like to request a working group last 
call.

Thanks,

--John

Begin forwarded message:

From: mailto:internet-dra...@ietf.org>>
Date: July 4, 2015 at 11:03:45 AM EDT
To: Stephen Stuart mailto:sstu...@google.com>>, John 
Scudder mailto:j...@juniper.net>>, "Rex Fernando" 
mailto:r...@cisco.com>>, Stephen Stuart 
mailto:sstu...@google.com>>, Rex Fernando 
mailto:r...@cisco.com>>, John Scudder 
mailto:j...@juniper.net>>
Subject: New Version Notification for draft-ietf-grow-bmp-09.txt


A new version of I-D, draft-ietf-grow-bmp-09.txt
has been successfully submitted by John Scudder and posted to the
IETF repository.

Name:draft-ietf-grow-bmp
Revision:09
Title:BGP Monitoring Protocol
Document date:2015-07-04
Group:grow
Pages:25
URL:https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/
Htmlized:   https://tools.ietf.org/html/draft-ietf-grow-bmp-09
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-09

Abstract:
  This document defines a protocol, BMP, that can be used to monitor
  BGP sessions.  BMP is intended to provide a more convenient interface
  for obtaining route views for research purpose than the screen-
  scraping approach in common use today.  The design goals are to keep
  BMP simple, useful, easily implemented, and minimally service-
  affecting.  BMP is not suitable for use as a routing protocol.




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<http://tools.ietf.org>.

The IETF Secretariat

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

Re: [GROW] RtgDir review: draft-ietf-grow-ix-bgp-route-server-operations-03.txt

[John Scudder]

On Oct 21, 2014, at 5:58 PM, Nick Hilliard  wrote:
...
> We'd prefer to leave the section in.

Ok. 

--John

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

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

[John Scudder]

Tim,

Thanks for your comments.  Your suggestions for the Initiation Message look 
like good stuff.  I would like to encourage the WG to brainstorm whether there 
are any other items to add to the laundry list (without boiling the ocean, 
please).  I'd also like to encourage any interested party including you to Send 
Text if you've a mind to.

The next hop thing is interesting, but I have to ask: can't you pull it out of 
the IGP already?  The reason we built BMP was because you just couldn't get the 
info you need by BGP peering with the router, so we had to come up with another 
way to externalize it.  This is not the case with the next hop stuff, is it?  I 
would prefer not to reinvent wheels if we can avoid it.

Regards,

--John

On Dec 1, 2011, at 2:01 PM, Evens, Tim wrote:

> Hi John et al., 
> 
> Below are some comments.
> 
> Initiation Message:
> 
> I like having Type-0 (free form text) but I think that some common
> information about the router/config should be consistently conveyed.
> My top of mind items are:
>   1) Router product vendor ID, such as the enterprise OID
>   2) Router hostname
>   3) Software version
>   4) Per Peer administrative configuration, such as:
>  4a) Description of peer
>  4b) peer-group name, if in peer-group
>  4c) flag to indicate if peer is IBGP-RR client or not
>  4d) aggregated list of filter names applied in/out (route-maps,
> import/export, prefix-lists,
>  filter-list) - vendor specific, but would allow management
> system to lookup the filters
>  applied or to validate correct filters are applied without
> having to query the router directly
>  via other means.
> 
> New BMP Message Type (IGP next-hops) :
> 
> We have developed a BMP server that collects the BMP messages, but without
> the IGP next hop metrics we are not able to do predictive calculations on
> the learnt prefixes.  The Loc-RIB sheds light into what the router has
> selected/installed, but it doesn't give the BMP server the ability to
> identify why those prefixes were preferred over another peer on the same
> router in terms of the next-hops.  Since the IGP next hops are not tied
> with BGP updates, it seems to make most sense to add a new message type
> "IGP next hop" that would convey the admin preferences/distance/metrics
> for BGP next hops.  No sense in advertising everything, just the next hops
> are needed.  Providing we have the IGP next hop information from the
> perspective of the router, we will be able to do predictive analysis on
> policy changes based on the Adj-RIB-In information.
> 
> The Loc-RIB information is still greatly needed since it provides details
> on which prefixes were actually installed, which helps confirm policy
> filters are working correctly.
> 
> 
> Thanks,
> 
> Tim
> 
> On 12/1/11 7:20 AM, "John Scudder"  wrote:
> 
>> Folks,
>> 
>> Changes between -05 and -06 are:
>> 
>> - Added "Lifecycle of a BMP Session" section.  It seemed as though people
>> really needed a little more context as to the expected sequence.
>> 
>> - Changed Message Length to 4 bytes.  (See
>> draft-ietf-idr-bgp-extended-messages-01 for some context as to why this
>> seemed like a good idea.)
>> 
>> - Changed Initiation Message string encoding from ASCII to UTF-8.
>> 
>> - Specified that Version 0 is reserved.
>> 
>> Regards,
>> 
>> --John
>> 
>> On Dec 1, 2011, at 10:14 AM,  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
>>> Working Group of the IETF.
>>> 
>>> Title   : BGP Monitoring Protocol
>>> Author(s)   : John Scudder
>>> Rex Fernando
>>> Stephen Stuart
>>> Filename: draft-ietf-grow-bmp-06.txt
>>> Pages   : 17
>>> Date: 2011-12-01
>>> 
>>>  This document proposes a simple protocol, BMP, which can be used to
>>>  monitor BGP sessions.  BMP is intended to provide a more convenient
>>>  interface for obtaining route views for research purpose than the
>>>  screen-scraping approach in common use today.  The design goals are
>>>  to keep BMP simple, useful, easily implemented, and minimally
>>>  service-affecting.  BMP is not suitable for use as a routing
>>>  protocol.
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org

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

[John Scudder]

Folks,

Changes between -05 and -06 are:

- Added "Lifecycle of a BMP Session" section.  It seemed as though people 
really needed a little more context as to the expected sequence.

- Changed Message Length to 4 bytes.  (See 
draft-ietf-idr-bgp-extended-messages-01 for some context as to why this seemed 
like a good idea.)

- Changed Initiation Message string encoding from ASCII to UTF-8.

- Specified that Version 0 is reserved.

Regards,

--John

On Dec 1, 2011, at 10:14 AM,  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 
> Working Group of the IETF.
> 
>   Title   : BGP Monitoring Protocol
>   Author(s)   : John Scudder
>  Rex Fernando
>  Stephen Stuart
>   Filename: draft-ietf-grow-bmp-06.txt
>   Pages   : 17
>   Date: 2011-12-01
> 
>   This document proposes a simple protocol, BMP, which can be used to
>   monitor BGP sessions.  BMP is intended to provide a more convenient
>   interface for obtaining route views for research purpose than the
>   screen-scraping approach in common use today.  The design goals are
>   to keep BMP simple, useful, easily implemented, and minimally
>   service-affecting.  BMP is not suitable for use as a routing
>   protocol.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt
> 
> ___
> 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] Call for WG Adoption - draft-shakir-idr-ops-reqs-for-bgp-error-handling

[John Scudder]

Yes please.

--John

On Apr 1, 2011, at 10:19 AM, Christopher Morrow wrote:

> (+wg this time, for realz)
> 
> On Fri, Apr 1, 2011 at 9:20 AM, Christopher Morrow
>  wrote:
>> Given the discussion in the room today, and the overlap of
>> readers-of-draft + folk-asking-for-adoption a call to the list is
>> appropriate.
>> 
>> For the draft: draft-shakir-idr-ops-reqs-for-bgp-error-handling
>>  
>> 
>> 
>> "BGP-4 is utilised as a key intra- and inter-Autonomous System routing
>>   protocol in modern IP networks.  The failure modes as defined by the
>>   original protocol standards are based on a number of assumptions
>>   around the impact of session failure.  Numerous incidents both in the
>>   global Internet routing table and within Service Provider networks
>>   have been caused by strict handling of a single invalid UPDATE
>>   message causing large-scale failures in one or more Autonomous
>>   Systems.
>> 
>>   This memo describes the current use of BGP-4 within Service Provider
>>   networks, and outlines a set of requirements for further work to
>>   enhance the mechanisms available to a BGP-4 implementation when
>>   erroneous data is detected.  Whilst this document does not provide
>>   specification of any standard, it is intended as an overview of a set
>>   of enhancements to BGP-4 to improve the protocol's robustness to suit
>>   its current deployment."
>> 
>> can we have some discussion about adoption in GROW for this at this
>> time, please?
>> 
>> Call ends 4/14/2011
>> 
>> Thanks!
>> -Chris
>> grow-wg-co-chair
>> 
> ___
> 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-05.txt

[John Scudder]

On Dec 16, 2010, at 8:08 PM, Stephen Stuart wrote:
>> I think it defeats a lot of use cases. Perhaps this subtle difference should
>> be discussed more before we proceed any further with this document.
> 
> This was discussed before, if I recall correctly.

That's correct.  In fact because of the divergence between -00 and -01, I took 
pains to make this clear when presenting -01, including at NANOG and GROW and 
probably other places.  Those interested in the history should be able to find 
the slides easily enough.

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

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

[John Scudder]

On Dec 15, 2010, at 6:16 PM, Nick Hilliard wrote:
> 1. please encode 1970-epoch timestamps as 64 bits, not 32.  32 bits will 
> break before I retire.

This is not out of the question, but keeping in mind that there's already 
implementation of the currently specified format, what is the value of making 
an incompatible change in order to avoid a wrap in 2106?  I'd think that given 
96 years to work on it and a grasp of modular arithmetic, it may be possible to 
work up BMP listeners that deal gracefully with the wrap.  Further feedback 
from the WG on this point would be welcome.

Also, out of curiosity, do you really expect to still be working in 2106?  

> 2. ASCII.  Sigh.

Colleagues keep threatening to educate me about text internationalization but 
it hasn't happened yet.  If someone would care to contribute the least-onerous 
possible revision that would make the spec internationally correct, that would 
be welcome.

> 3. maybe TLS/SSL instead of ipsec?  It's not that I loathe ipsec (I don't); 
> it's just that ssl is much easier to implement, as there are well 
> understood client system APIs for it.

IPSec is exemplary, not normative.  TLS/SSL is another example, we can mention 
it and list in the Informative References too if folks feel that would be 
helpful.

> 4. address encoding: would it not be wise from an implementation point of 
> view to include the protocol number near the address fields, on the basis 
> that ipv4 == len(4) and ipv6 == len(16) is, well, a bit hacky?  What if 
> there's some other protocol in future which might want to use BMP?

I won't argue it's not a bit hacky but it's a fairly common idiom. As a 
practical matter, BMP is pretty tightly bound to BGP and BGP is only specified 
over v4 and v6.  I won't argue that generality isn't good in principle though, 
all things being equal.

Feedback from the WG on this point would also be welcome, again bearing in mind 
that there's already running code.  

Regards,

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

[GROW] RTGWG WGLC on draft-ietf-grow-bgp-graceful-shutdown-requirements-06

[John Scudder]

RTGWG Folks,

This is to begin an RTGWG working group last call on 
draft-ietf-grow-bgp-graceful-shutdown-requirements-06.  Please send comments by 
November 18, 2010.  Please cc the GROW list.  As Bruno noted in his earlier 
email, the document has already been WGLC'd in GROW but the IESG requested 
additional review, in particular related to IPFRR.

URLs for the draft and related presentation are found in Bruno's email sent a 
few hours ago.

Thanks,

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

[GROW] Fwd: New Version Notification for draft-wkumari-deprecate-as-sets-00

[John Scudder]

[bcc to GROW mailing list]

Folks,

FYI.  I'd be interested in discussion of this topic.

For your clicking pleasure, 
http://tools.ietf.org/html/draft-wkumari-deprecate-as-sets-00

--John

Begin forwarded message:
> From: IETF I-D Submission Tool 
> Date: August 31, 2010 9:26:21 PM EDT
> Subject: New Version Notification for draft-wkumari-deprecate-as-sets-00 
> 
> 
> A new version of I-D, draft-wkumari-deprecate-as-sets-00.txt has been 
> successfully submitted by Warren Kumari and posted to the IETF repository.
> 
> Filename:  draft-wkumari-deprecate-as-sets
> Revision:  00
> Title: Deprecation of BGP AS_SET.
> Creation_date: 2010-08-31
> WG ID: Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This document deprecates the use of the AS_SET type of the AS_PATH in
> BGPv4.  This is done to simply the design and implementation of the
> BGP protocol and to make the semantics of the originator of a route
> more clear.
> 
> 
> 
> The IETF Secretariat.

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

Re: [GROW] Chairs to petition IANA for a codepoint for GEO-MRT

[John Scudder]

On Jul 29, 2010, at 3:21 PM, Christopher Morrow wrote:
> (from Jeff Haas)
> The chairs need to petition IANA sooner rather than later to reserve a
> table type number for the geo type in the mrt type field.

I thought Jeff was saying that the registries haven't been set up yet and 
should be.  IANA would normally do this when you move the MRT draft to RFC but 
it might be worth doing sooner.  The MRT draft sez:

6.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the MRT
   specification, in accordance with BCP 26, RFC 5226 [RFC5226].

   There are two name spaces in MRT that require registration: Type
   Codes and Subtype Codes.

 [...etc...]

By the way Terry asked what kind of type code to ask for.  The MRT draft sez:

6.1.  Type Codes

   Type Codes have a range from 0 to 65535, of which 1-64 have been
   allocated.  New Type Codes MUST be allocated starting at 65.  Type
   Codes 65 - 511 are to be assigned by IETF Review.  Type Codes 512 -
   2047 are assigned based on Specification Required.  Type Codes 2048 -
   64511 are available on a First Come First Served policy.  Type Codes
   64512 - 65534 are available for Experimental Use. The Type Code
   Values of 0 and 65535 are reserved.

I can't quite imagine why you'd bother with the hoop-jumping required by IETF 
Review.  If I were you, I'd probably just use an FCFS code point.  Numbers is 
numbers after all, they all work the same.

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

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

[John Scudder]

On Jun 24, 2010, at 11:13 AM, Larry Blunk wrote:
> I recall that John did initially look at the MRT format, but
> ran into some issues.   Unfortunately, I don't quite remember
> what they were.   John should be able to detail the issues.

That was quite a while ago so my memory of details is pretty fuzzy.  Glancing 
through draft-ietf-grow-mrt-11 I see that there is a significant (say, 80%) 
syntactic overlap between MRT's BGP4MP_MESSAGE_AS4 + BGP4MP_ET and BMP's Route 
Monitoring message.   As Claudio points out, syntax is easy, MRT could 
presumably be updated to carry the extra bits BMP has that MRT doesn't. 

Syntactic similarity notwithstanding, I have misgivings about attempting a 
merger.  Although MRT and BMP cover similar problem spaces and the syntaxes 
could be brought into alignment, the semantics are different.  I think this is 
not an accident and is caused by different design constraints.  I won't presume 
to say what the assumptions were for MRT, but the high-level goals for BMP are 
spelled out in the abstract: "The design goals are to keep BMP simple, useful, 
easily implemented, and minimally service-affecting."  In particular, the 
"minimally service-affecting" (for a live, busy production router) goal turns 
out to have had extensive consequences.

Here are some of the substantive differences between MRT and BMP:

- MRT table dump uses a special format.  BMP table dump is just a case of 
sending encapsulated Update messages, followed by an EoR.
- MRT uses BGP4MP_MESSAGE messages to convey verbatim copies of update messages 
(Larry tells me that "the BGP messages are just copied in network byte order 
into the BGP Message field").  BMP Route Monitoring messages are generated 
afresh by the monitored router based on its RIB contents (the spec points out 
that "It's important to note that RM messages are not real time replicated 
messages received from a peer").

The above reflects my understanding of MRT from reading the spec and (in some 
cases) checking with Larry.  The spec is a little light on defining semantics 
so in some cases I'm not 100% positive I have the right reading.

Based on these differences, I wouldn't guess that an MRT listener could consume 
the output of a BMP speaker, even if the BMP speaker were updated to use MRT 
message formats.  Similarly, it wouldn't be easy to convert a BMP speaker to 
provide MRT output (in fact, if BGP4MP_MESSAGE_* are really supposed to encap 
update messages as received, that's an explicit non-goal of BMP for scalability 
reasons).

In sum, I question whether there is anything much to be gained from a merger.  
There's certainly something to be lost, in terms of delaying progress on BMP 
implementations.

I'm thinking of adding a "comparison with MRT" appendix to the next version of 
the BMP draft since this question has come up a few times now.

Thanks to Larry for answering my questions about MRT.

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

Re: [GROW] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-grow-va-02

[John Scudder]

On Jun 24, 2010, at 11:10 AM, Christopher Morrow wrote:
> my feeling is if the autoconfig isn't necessary, and is encumbered how
> about we live without it if possible :)

My question on this is the same as always -- considering that the lack of a 
patent disclosure does NOT guarantee that a technology is unencumbered, what do 
we gain by penalizing technologies for which a disclosure has been filed?  In 
fact, from one point of view there is something to be preferred about a spec 
with an above-board RAND disclosure over a spec with no disclosure but that may 
be covered by some submarine patent held by a troll.  I see an argument in 
favor of preferring a positively-known-to-be-unencumbered technology, but AFAIK 
that is a completely hypothetical case.

(You would be wrong if you interpreted this as "John is happy with the state of 
patent law".  The above represents my view of reality-as-it-is.  My view of 
reality-as-I-wish-it-was is not particularly relevant, AFAICT.)

--John
  with my own individual contributor hat on, of course
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[John Scudder]

FYI the changes in this version are summarized as

o  Require End-of-RIB marker after initial dump.
o  Added Initiation message with string content.
o  Changed assignment policy for IANA registries.   
o  Editorial changes.

I think this is fairly well baked.  I believe we've incorporated all feedback 
to date, so if you had a comment outstanding, please double-check it.

--John

On Jun 14, 2010, at 10:45 AM,  
 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 Working Group of 
> the IETF.
> 
> 
>   Title   : BGP Monitoring Protocol
>   Author(s)   : J. Scudder, et al.
>   Filename: draft-ietf-grow-bmp-04.txt
>   Pages   : 16
>   Date: 2010-06-14
> 
> This document proposes a simple protocol, BMP, which can be used to
> monitor BGP sessions.  BMP is intended to provide a more convenient
> interface for obtaining route views for research purpose than the
> screen-scraping approach in common use today.  The design goals are
> to keep BMP simple, useful, easily implemented, and minimally
> service-affecting.  BMP is not suitable for use as a routing
> protocol.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

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