[GROW] Re: [Sidrops] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6

[Claudio Jeker]

On Thu, Aug 22, 2024 at 03:46:11AM +, Sriram, Kotikalapudi (Fed) wrote:
> [Jeff, Ketan, Sue, Keyur, all ... please share if you have some thoughts 
> about this]
> 
> Hi Claudio,
> 
> >If a router sends you an AS_PATH without AS_SET and an AS4_PATH with AS_SET 
> >
> 
> You raise a good question.  Section 3.1 observations are based on the
> premise that if RFC6793 is implemented correctly by the sender and
> preceding ASes in the AS path, then the above will not happen. But you
> think it could happen due to an intentional attack by the sender or a
> preceding AS.

If systems implement RFC6793 then why are they running without 4-byte ASN
in the first place?
Systems that only support 2-byte ASN do not follow RFC6793 since they
don't support it. So you can not assume they will do anything regarding
RFC6793 correctly. I doubt this is a widespread issue but at the same time
this is a possible attack vector and security concern. It is a loop hole
which should be closed.
 
> All:
> 
> OK, let us see if we can address this.  
> 
> Which of the following methods for modifying the recommendations at the top 
> of Section 3 would be preferable (click to see Sec. 3: 
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-15#name-recommendations
>  )?
> 
> Method A:  Modify the second bullet in Sec. 3 as follows:
> 
> * Upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs 
> in the AS_PATH or AS4_PATH, MUST use the "treat-as-withdraw" error handling 
> behavior as per [RFC7606].
> 
> Methos B.  The second bullet in Sec. 3 remains as is but add a third bullet 
> as follows:
> 
> (unchanged second bullet)
> * Upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs 
> in the AS_PATH, MUST use the "treat-as-withdraw" error handling behavior as 
> per [RFC7606].
> 
> (new third bullet)
> * Upon reception of BGP UPDATE messages not containing AS_SETs or 
> AS_CONFED_SETs in the AS_PATH but containing AS_SETs in the AS4_PATH, MUST 
> use the "attribute discard" approach for the (malformed) AS4_PATH as per 
> [RFC7606].
> 
> Note (with Choice B): The handling of UPDATES with AS_CONFED_SETs in the 
> AS4_PATH is as specified in [RFC6793].

We did implement choice B and are therefor in favour of this method.
 
> Thanks for you anticipated inputs.
> 
> Sriram   
> 
> -Original Message-
> From: Claudio Jeker  
> Sent: Tuesday, August 20, 2024 9:29 AM
> To: i...@ietf.org
> Subject: [Idr] Re: I-D Action: 
> draft-ietf-idr-deprecate-as-set-confed-set-15.txt
> 
> On Mon, Aug 19, 2024 at 11:21:37AM -0700, internet-dra...@ietf.org wrote:
> > Internet-Draft draft-ietf-idr-deprecate-as-set-confed-set-15.txt is 
> > now available. It is a work item of the Inter-Domain Routing (IDR) WG of 
> > the IETF.
> > 
> >Title:   Deprecation of AS_SET and AS_CONFED_SET in BGP
> >Authors: Warren Kumari
> > Kotikalapudi Sriram
> > Lilia Hannachi
> > Jeffrey Haas
> >Name:draft-ietf-idr-deprecate-as-set-confed-set-15.txt
> >Pages:   15
> >Dates:   2024-08-19
> > 
> > Abstract:
> > 
> >BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
> >AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol
> >(BGP).  This document advances that recommendation to a standards
> >requirement in BGP; it prohibits the use of the AS_SET and
> >AS_CONFED_SET path segment types in the AS_PATH.  This is done to
> >simplify the design and implementation of BGP and to make the
> >semantics of the originator of a BGP route clearer.  This will also
> >simplify the design, implementation, and deployment of various BGP
> >security mechanisms.  This document updates RFC 4271 by deprecating
> >the origination of BGP routes with AS_SET (Type 1 AS_PATH segment)
> >and updates RFC 5065 by deprecating the origination of BGP routes
> >with AS_CONFED_SET (Type 4 AS_PATH segment).  Finally, it obsoletes
> >RFC 6472.
> > 
> 
> I had a look at this draft and think
> Section 3.1 Considerations for AS4_PATH needs to be adjusted.
> 
> 3.1.  Considerations for AS4_PATH
> 
>[RFC6793] created support for four-octet AS numbers in BGP using the
>optional transitive AS4_PATH attribute.  The mandatory AS_PATH
>attribute is always present in a route [RFC4271], while the AS4_PATH
>may or may not be present.  If both AS_PATH and AS4_PATH attributes
>are present, an AS_SET present in one would also be necessarily
>present in the other.  So, it is suffi

[GROW] Re: [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6

[Claudio Jeker]

On Tue, Aug 20, 2024 at 04:30:36PM +, Susan Hares wrote:
> Sriram and Ketan:
> 
> We will close the WG LC when Ketan responds to a query about whether
> -15.txt resolves the issues.

Please also consider my issue I raise with the newly introduced section
3.1 before closing the WG LC.
 
> Sue
> 
> From: Sriram, Kotikalapudi (Fed) 
> Sent: Monday, August 5, 2024 11:12 AM
> To: Ketan Talaulikar 
> Cc: i...@ietf.org; sidr...@ietf.org; grow@ietf.org
> Subject: Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 
> 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
> 
> Hi Ketan, Thank you for meeting with the draft authors in a side-meeting in 
> Vancouver (IETF 120) to offer your comments. You gave us the following 
> wording suggestion for inclusion in the draft: Unless
> External (kotikalapudi.sri...@nist.gov)
>   Report This 
> Email
>   
> FAQ
>   GoDaddy Advanced Email Security, Powered by 
> INKY
> 
> 
> Hi Ketan,
> 
> 
> 
> Thank you for meeting with the draft authors in a side-meeting in Vancouver 
> (IETF 120) to offer your comments.
> 
> 
> 
> You gave us the following wording suggestion for inclusion in the draft:
> 
> 
> 
> Unless explicitly configured by a network operator to do otherwise (e.g., 
> during a transition phase), BGP speakers
> 
> - MUST NOT advertise BGP UPDATE messages containing AS_SETs or 
> AS_CONFED_SETs, and
> 
> - Upon reception of BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs, 
> MUST use the "treat-as-withdraw" error handling behavior as per [RFC7606].
> 
> 
> 
> This wording seems perfect and should satisfy many of the WG members who gave 
> feedback.  AFAIK, the authors who met with you (Jeff, Warren, and I) agree 
> with your suggestion. I have included this text in my editor copy of the 
> draft replacing the first paragraph in Sec. 3 (v-14). We'll also make text 
> changes elsewhere in the draft where needed to be consistent with this change.
> 
> 
> 
> Sriram

> ___
> Idr mailing list -- i...@ietf.org
> To unsubscribe send an email to idr-le...@ietf.org


-- 
:wq Claudio

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

Re: [GROW] Limiting AS path length?

[Claudio Jeker]

On Tue, Sep 17, 2019 at 11:36:18PM +, john heasley wrote:
> Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker:
> > > And what if I make it 675 ASes instead and watch sparks fly as a few
> > > hops away routers hit the 4096-byte BGP message size?
> > > 
> > > Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit
> > > AS path, so the first 32-bit router that tries to create a 700-hop
> > > 32-bit AS path exceeds 4096 bytes?
> > 
> > You are applying a band-aid to a broken bone. There is many more ways you
> > can push an UPDATE to over 4096 bytes. Using AS path alone is probably the
> > least successful. There are many more transitive attributes that you can
> > use to bloat an update. So whatever limit you come up with will not
> > protect you from tripping over the message size limit.
> > 
> > It would be great if there is a standards document properly describing
> > what to do in such a case because this is one of the underspecified corner
> > cases in the current spec.
> 
> isnt this rfc7606

I only see input related checks in rfc7606 and there is nothing describing
what to do when the total lenght of an UPDATE exceeds 4096 bytes. At least
I did not spot it.

draft-ietf-idr-bgp-extended-messages-36 has a paragraph covering how to
handle oversized messages:

   A BGP speaker that has advertised the BGP Extended Message capability
   to its peers, may receive an UPDATE from one of its peers that
   produces an ongoing announcement that is larger than 4,096 octets.
   When propagating that UPDATE onward to a neighbor which has not
   advertised the BGP Extended Message capability, the speaker SHOULD
   try to reduce the outgoing message size by removing attributes
   eligible under the "attribute discard" approach of [RFC7606].  If the
   message is still too big, then it must not be sent to the neighbor
   ([RFC4271], Section 9.2).  Additionally, if the NLRI was previously
   advertised to that peer, it must be withdrawn from service
   ([RFC4271], Section 9.1.3).

Hopefully implementations will pick up this approach independent from the BGP
Extended Message Capability.

-- 
:wq Claudio

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

Re: [GROW] Limiting AS path length?

[Claudio Jeker]

On Mon, Sep 16, 2019 at 09:54:36PM +0200, Iljitsch van Beijnum wrote:
> On 16 Sep 2019, at 20:37, Job Snijders  wrote:
> 
> > Limiting the AS_PATH length - from an IETF RFC publication process in 
> > context of providing operational guidance, probably shouldn’t be “limit the 
> > path length to avoid vendor bugs”. 
> 
> > Instead, the guidance perhaps should be “please report and fix bugs”, 
> > right? :-)
> 
> In theory, yes. In practice, how does that work? Suppose I prepend 250
> times, and a few hops away, routers start to explode because they hit
> 255 or 256 ASes in the path? How do these people debug the issue? Once
> they know the problem, how do they install a temporary fix as they wait
> for a real fix?
> 
> Also, it's unlikely that any given bug will ever be completely
> eradicated from the internet even if fixed software is available. The
> real time global nature of BGP routing makes all of this much more
> complex.

As one person writing BGP routing software I need to say that these
issues are on us to fix and people should complain loudly about them.
Writing a test with e.g. exabgp to exactly check this condition is not
hard and can be added to any regress test. So having such a bug in
production software is not acceptable.
Also not updating your infrastructure systems is not acceptable either
especially if you are providing transit to other customers that pay you.
 
> And what if I make it 675 ASes instead and watch sparks fly as a few
> hops away routers hit the 4096-byte BGP message size?
> 
> Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit
> AS path, so the first 32-bit router that tries to create a 700-hop
> 32-bit AS path exceeds 4096 bytes?

You are applying a band-aid to a broken bone. There is many more ways you
can push an UPDATE to over 4096 bytes. Using AS path alone is probably the
least successful. There are many more transitive attributes that you can
use to bloat an update. So whatever limit you come up with will not
protect you from tripping over the message size limit.

It would be great if there is a standards document properly describing
what to do in such a case because this is one of the underspecified corner
cases in the current spec.
 
> Now all of these problems can easily be avoided by a 120 or so AS limit.
> Currently, the longest path that I see at Routeviews is 45, with 40
> prepends. (That same network also advertises about a /13 worth of space
> as 2200 individual /24s for good measure.) 120 won't be hitting any
> overflow bugs, but it's still rather excessive at three times the
> longest non-prepended path. Also, 40 prepends is not going to give you
> anything that 39 prepends, or 30 or 20, for that matter, won't
> accomplish.
> 
> I've seen max path length limits of 40 or even as low as 20 mentioned.
> 
> But before we decide _where_ to draw the line, we first have to decide
> if we think this particular line should be drawn at all. It looks to me
> like AS path length filtering is sufficiently common that trying to come
> up with a coordinated limit as a best practice would be worthwhile.
> 
> (BTW, as far as I'm concerned we deprecate the use of AS_SETs and
> multiple AS_PATHs in order to remove some unnecessary complexity from
> BGP.)

It would be great if all the 2-byte AS complexity could be slowly removed.
Allow systems to no longer accept sessions without the 4-byte AS
capability and remove all the code to generate and merge AS4_PATH and
friends.

-- 
:wq Claudio

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

Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

[Claudio Jeker]

On Fri, Jul 26, 2019 at 02:49:55PM +, Job Snijders wrote:
> Dear Robert,
> 
> Thank you for your questions.
> 
> On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote:
> > I would like to raise three points in respect to this draft:
> > 



> > Point 3:
> > 
> > For inbound prefix limit the position if this should be pre or post
> > policy should be IMHO a local configuration decision. See if I decide
> > to keep full table in my Adj_RIB_In maybe just for BMP use no spec
> > should prevent that.  Maybe it would be worth to add this explicitly
> > to the draft in addition to listing those two measurement insertion
> > locations :)
> 
> I agree that operators locally configure these limits and they
> themselves choose to use no limits, pre-, post-, or a combination of
> pre- + post- policy limits.
> 
> This Internet-Draft seeks to document that both exist, and formulate
> things in such a way that when a vendor claims compliance with
> draft-sa-grow-maxprefix, they indicate to support all of outbound,
> pre-policy inbound, and post-policy inbound. A vendor could also
> indicate they only have support for "draft-sa-grow-maxprefix section 2.2
> type B", or only "type A".
> 
> My recommendation to BGP implementers would be to implement all three
> types of prefix limits. My recommendation to operators is to configure
> both pre-policy and post-policy limits, as each limit has different
> advantages in context of Internet routing.

For BGP implementation having more then just one Loc-RIB implementing a
post-policy check is more comples and the result will depend on which of
the RIBs the count is done. For this reasons OpenBGPD only does pre-policy
inbound limits and until now nobody ever complained about that being not
good enough.

-- 
:wq Claudio

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

Re: [GROW] A new bgpdump tool

[Claudio Jeker]

On Fri, Mar 20, 2015 at 09:15:50AM +, Nick Hilliard wrote:
> On 20/03/2015 06:48, Claudio Jeker wrote:
> > OpenBGPD's bgpctl is able to read mrt dump files as well. Currently only
> > table dumps are supported though.
> > 
> > - openbgpd bgpctl
> >   written in C.
> >   http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpctl/
> 
> Hi Claudio,
> 
> Are there any plans to support this on operating systems other than openbsd?

Some people ported it to FreeBSD and NetBSD. I also heard of a Linux
version (without FIB support). I personally do not plan to port OpenBGPD
to other platforms (there is more important things I like to implement in
OpenBGPD) but I'm happy to adjust our code to make porting easier.

-- 
:wq Claudio

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

Re: [GROW] A new bgpdump tool

[Claudio Jeker]

On Fri, Mar 20, 2015 at 10:15:40AM +0900, Yasuhiro Ohara wrote:
> 
> Hi,
> 
> > tools. I'm going to summarize it and send the list to the mailing-list.
> 
> Below is the list of tools and some papers.
> 
> * Tools.
> 
> - libbgpdump
>   written in C.
>   
> 
> - zebra-dump-parser
>   written in Perl.
>   
> 
> - java-mrt library
>   written in Java.
>   
> 
> - UCLA bgpparser
>   written in C++.
>   
> 
> - mrtparse
>   written in Python.
>   
> 
> - bgpdump2
>   written in C.
>   
> 
> 
> * route leaks
>   - 
> 
>   - 
> 
>   - 
> 
> (to be presented in the IDR WG meeting in Dallas)
> 

OpenBGPD's bgpctl is able to read mrt dump files as well. Currently only
table dumps are supported though.

- openbgpd bgpctl
  written in C.
  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpctl/

Cheers
-- 
Claudio

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

Re: [GROW] MRT

[Claudio Jeker]

On Wed, Nov 28, 2012 at 06:47:02PM +0100, Pedro Andres Aranda Gutierrez wrote:
> I had to write my own MRT parser library for my PhD. After my defense
> next January, I plan to release it. (one step at a time, I'm quite
> busy right now preparing the defense ;-) ) It's written in Java. Re:
> pybgpdump, I have to agree it's a very nice tool once you patch dpkt
> :-) re libbgpdump, it compiles, it helped me kick-start my research,
> but that's it.
> 

OpenBGPD has a mrt parser in bgpctl. It is mainly for table dumps but
the basic framework for dumping bgp messages there. I have a diff that 
uses the tcpdump BGP protocol parser to dump those messages. If interested
just drop me a mail.

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

Re: [GROW] RFC 6396 on Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format

[Claudio Jeker]

Ugh, it is unfortunate that a RFC was pushed that is incompatible with the
largest collection of MRT files. The RIPE RIS project dumps their data in
a different TABLE_DUMP_V2 format. Also unfortunate is that the example in
Apppendix A in the RFC itself is not compatible with the RFC -- appart
from having a badly encoded MP_REACH_NLRI attrubute in it (which I just
realized now).

The problem is that at least quagga does not follow the RFC in regards of
encoding the MP_REACH_NLRI. Instead of dumping the data only with the
nexthop len and nexthop information the full MP_REACH_NLRI is dumped.
AFAIK quagga is appart from OpenBGPD-current the only other bgp daemon
able to create TABLE_DUMP_V2 dumps and because of the RIPE RIS project
also probably the defacto standard. So people implementing MRT parsers
based on the RFC will be in for a surprise when looking at the most
commonly available MRT dumps.

-- 
:wq Claudio

On Mon, Oct 31, 2011 at 09:52:15PM -0700, rfc-edi...@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 6396
> 
> Title:  Multi-Threaded Routing Toolkit (MRT) Routing 
> Information Export Format 
> Author: L. Blunk, M. Karir,
> C. Labovitz
> Status: Standards Track
> Stream: IETF
> Date:   October 2011
> Mailbox:l...@merit.edu, 
> mka...@merit.edu, 
> labo...@deepfield.net
> Pages:  33
> Characters: 73982
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-ietf-grow-mrt-17.txt
> 
> URL:http://www.rfc-editor.org/rfc/rfc6396.txt
> 
> This document describes the MRT format for routing information
> export.  This format was developed in concert with the Multi-threaded
> Routing Toolkit (MRT) from whence the format takes it name.  The
> format can be used to export routing protocol messages, state
> changes, and routing information base contents.  [STANDARDS-TRACK]
> 
> This document is a product of the Global Routing Operations Working Group of 
> the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   http://www.ietf.org/mailman/listinfo/ietf-announce
>   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> 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-mrt-15.txt

[Claudio Jeker]

On Thu, Jul 07, 2011 at 09:51:39AM -0400, Larry Blunk wrote:
> On 07/07/2011 07:37 AM, Nick Hilliard wrote:
> >>This document describes the MRT format for routing information
> >>export.  This format was developed in concert with the Multi-threaded
> >>Routing Toolkit (MRT) from whence the format takes it name.  The
> >>format can be used to export routing protocol messages, state
> >>changes, and routing information base contents.
> >
> >Similar to BMP, MRT uses 32 bit timestamps.
> >
> >Once again, the issue is a question of whether to take a pain hit now,
> >while MRT still has a relatively small install base, or whether to take a
> >much, much bigger pain hit when we reach 2038 when we have much wider
> >deployment of MRT + a whole pile of archived records to deal with (as we're
> >talking about an archive storage mechanism here).
> >
> >Personally, I'm not a fan of kicking cans down the road.
> >
> >The standard also lacks a version field in the headers.  If the authors
> >were to decide that changing the header might be in the protocol's
> >long-term interest, then adding a version field would probably be a good 
> >idea.
> >
> >Nick
> >[as with my previous comments on the BMP ID, apologies for jumping in with
> >a fundamental change suggestion like this on a -15 draft.]
> >___
> 
> 
>   Nick,
> These issues were brought up in the IESG last call (lack
> of version number + 32 bit timestamps).   Rather than
> attempting to apply more band-aids to the specification,
> a decision was made that a clean slate design would be
> a better choice and the draft was changed from Standards
> Track to Informational.  There's an expired draft with
> a proposed XML based format --
> http://tools.ietf.org/html/draft-cheng-grow-bgp-xml-00
> with an implementation available at
> http://bgpmon.netsec.colostate.edu/
> 

I hope this is more of a joke than something taken seriously.
The RIPE provided MRT V2 table dumps are around 400MB each.
The V2 table dump format tries to be as compact a possible whereas this
XML format is super verbose (the shown keepalive is around 1000 bytes
instead of 19 and an update will be easily in the 10k range).
Also parsing XML will probably take magnitudes more times and the needed
memory and disk space will make analysing and archiving a painful task.
IMO this proposal is unusable for the real world.

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

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

[Claudio Jeker]

On Mon, Jun 21, 2010 at 12:45:00PM -0400, Christopher Morrow wrote:
> On Mon, Jun 21, 2010 at 12:31 PM, Claudio Jeker
>  wrote:
> > On Mon, Jun 14, 2010 at 07:45:24AM -0700, 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 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
> >>
> >
> > I'm wondering why it is necessary to have a new way of dumping tables and
> > updates. IMO the MRT format is a very well known and accepted format.
> > There are existing parser libraries and many bgp implementations already
> > support this format.
> > Wouldn't it be better to make a joined effort to merge MRT and BMP?
> 
> bmp dumps the adj-rib-in ... with (I believe) some extra data that
> MRT's not getting. I thought also that larry was looking to integrate
> BMP feeds into the collector system that uses MRT today? (mrt being
> the output format from a bgp listener like quagga)
> 

Which table is dumped is only an implementation detail. MRT could very
well dump the adj-rib-in or even the adj-rib-out. Some implementations do
allow that already.

It is very simple to extend the MRT format for the two new messages that
BMP has. Adding the Initiation Message and Stats Reports to MRT would
be simple.

I just see no point in trying to reinvent the wheel.
-- 
:wq Claudio
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Claudio Jeker]

On Mon, Jun 14, 2010 at 07:45:24AM -0700, 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 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
> 

I'm wondering why it is necessary to have a new way of dumping tables and
updates. IMO the MRT format is a very well known and accepted format.
There are existing parser libraries and many bgp implementations already
support this format.
Wouldn't it be better to make a joined effort to merge MRT and BMP?

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