Fwd: WG Last Call on draft-ietf-idr-bgp-model-16

[Jeffrey Haas]

The IETF BGP YANG module authors would like to draw your collective attention 
to a Working Group Last Call that has begun for the IETF BGP YANG module.

This module provides the base for core IETF BGP technologies, and will serve as 
the primary point of extension for BGP-related technologies modeled in YANG in 
the IETF, including the BGP portion of VPN technologies.

Your operational wisdom and scrutiny would be greatly appreciated.

A URL for the WGLC mail is here:
https://mailarchive.ietf.org/arch/msg/idr/263_yrn_ZnNRokmUwgye7Id5mHo/

For those of you who haven't participated in IETF mail lists before, the IDR 
datatracker page has subscription information for the mailing list:
https://datatracker.ietf.org/wg/idr/about/

Thanks!

-- Jeff (for the authors)

> Begin forwarded message:
> 
> From: "Dongjie (Jimmy)" 
> Subject: WG Last Call on draft-ietf-idr-bgp-model-16
> Date: April 10, 2023 at 10:17:26 PM EDT
> To: "i...@ietf.org" 
> Cc: "idr-cha...@ietf.org" , "Dongjie (Jimmy)" 
> 
> Resent-From: 
> Resent-To: s...@ndzh.com, ke...@arrcus.com, jh...@pfrc.org, 
> jie.d...@huawei.com
> 
> Hi WG, 
>  
> This begins the Working Group Last Call for "YANG Model for Border Gateway 
> Protocol (BGP-4)", draft-ietf-idr-bgp-model-16. The draft could be found at: 
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16 
> . 
>  
> Since all the IDR chairs are coauthors of this document, I’m helping with 
> this last call procedure. Please reply to the list with your comments. 
> Considering this is a long document with a big YANG model, the last call will 
> last for 4 weeks and conclude on Sunday, 7 May, 2023.
>  
> The authors are requested to state whether they are aware of applicable IPR 
> related to this draft. Similarly, if others in the Working Group are aware of 
> applicable IPR, please also disclose them.
>  
> People are encouraged to indicate whether there is implementation of this 
> document. According to the IDR rule, at least two implementations will be 
> required to advance the document.
>  
>  
> Best regards,
> Jie (on behalf of the IDR chairs)

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

On Fri, Aug 20, 2021 at 04:04:35PM -0300, Douglas Fischer wrote:
> About the cone definition (by AS-SET) of IXPs... This is an especially
> important thing.
> But, unless some external force come to push the IXPs to do it, I don't see
> that we will have that so soon.

The IXP would need to have a mechanism that fits nicely into their route
server and operational infrastructure.  The mechanism I was referring to
previously for having it in their IRR was how the RSng infrastructure Merit
operated years ago worked.  In those days, the route server was the ISI
software.

(Note that this is historical.)

> About the use of RT-Constrain as a "please give that" tool, Robert
> mentioned SAFI 1, but...
> I don't see how to use that on the actual BGP engines on the tradicional
> BGP sessions. Even considering semantic limitation you mentioned.

Code-wise, it's simple.

Operationally, it's an interesting mess.  Rt-Constrain is a filter that says
"if you have one of these Extended Communities, you can send it".  This
means you'd need to tag EVERYTHING - and that may be operationally
problematic for Internet routes.

Some of the related issues are tangentially covered in a proposal to do
Rt-Constrain on things other than just Extended Communities.

https://datatracker.ietf.org/doc/html/draft-zzhang-idr-bgp-rt-constrains-extension-01

> I was reading some drafts and this one caught my attention.
> https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/
> 
> That idea of Wide Communities is a one-fit-all tool.
> Maybe using the feature that will come from this Draft on another way, it
> could do the "please give that" job.

While I'm clearly a fan of Wide communities, I'd suggest that running an
entire deployment via the -rpd mechanism still seems operationally
challenging.  I guess we'll see how that works out.

-- Jeff

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

> On Aug 19, 2021, at 9:04 AM, james jones  wrote:
> 
> PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
> used regex lib these day anyways. I also thought it was already in Junos.

Junos is a very wide topic.

In Juniper's BGP implementation, there are two regular expression engines: one 
for communities, one for as-paths.  Neither are PCRE.

The implementation of regular expression matching in high availability software 
is a bit of a talk all on its own.

-- Jeff

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

> On Aug 19, 2021, at 12:18 AM, Douglas Fischer  
> wrote:
> 
> I agree that without combining prefix-list and as-path, the effectiveness of 
> ORF, considering its initial purpose, the pros and cons does not pay 
> themselves.
> 
> 
> But (there is always a but), I was imagining a different use for 
> ext-community-orf !
> 
> Considering scenarios like:
>  -  Route-Servers of big IXPs, now days with almost 200K routes.
>  - Transit providers sending its own point of view of DFZ with almos 900K 
> routes.
> On both cases, informative communities are an excelente way to decide "what 
> is good for my ASN, and what is not".
> 
> Yes, I know that is possible to filter based on that after receiving those 
> routes.
> But it takes computational effort on both sides to do that.
> And I imagine that comparing to AS-Path Regex, the needed computational 
> effort and the complexity of the logics to do filtering based on 
> community-list are much smaller.
> 
> 
> So, if I could say:
>  "Hey Mr. Route-Server... how are you?
>  Could you please not send-me the routes that are tagged with the 
> community ?
>  And after that, send-me just the routes that are tagged with the 
> community ?"
> In a Route-Server context, beyond reduce the number of BGP Messages that 
> would be great for the CPU/Memory consumption both, RS and RS-Client.
> 
> Or, in a Transit context...
> 1 - Customer opens a ticket with support team to set the export filter to 
> send only default-route.
> 2 - Customer, 5 days later, opens a ticket with support team re-adjust the 
> export filter, now sending full-routing.
> 3 - Customer, on next month, opens another ticket with support team to send 
> only the cone at right of the ASN of ITP.
> With a good and public informative communities policy and ext-community-orf, 
> the transit customer could change what his router will receive from the BGP 
> transit Peer, depending only on himself.
> 
> 
> Well... I don't really know how complex is to deal with that again on a WG.
> But I would like to see that.

Once upon a time, people would register their filtering intent with a local IRR 
and the route server would simply construct the necessary view for them.  It 
seems like IXPs have gotten out of that habit.

As Robert notes elsewhere, RT-Constrain is something that might work fine if 
implementations support filtering vs. non-VPN famlies with it.  However, that's 
still somewhat problematic for the type of scenario you're discussing.

Rt-Constrain is intended to be a pull protocol for positive state.  Basically, 
"send me things that have X route-target extended community in it".  While it's 
possible that IXP process might map well to that semantic with some careful 
planning, much of the time the desire is for filtering out of stuff - the 
opposite semantic.  So, this becomes an awkward fit for Rt-Constrain.  Even for 
the previously discussed ORFs, this is awkward and that's part of the 
discussion about the RD-ORF proposal.

An example of something that would fit modestly well for Rt-Constrain is routes 
are tagged by the IXP with a route-target that has the AS of the IXP 
participant.  You then send in a Rt-Constrain route for each of the ASes you 
want to pull from the RS.  But as noted, this means applying Rt-Constrain to 
non-VPN families which not all implementations do.  (I keep intending to do the 
work in Juniper's implementation, but the round-tuit vs. fighting our process 
get in the way...)

-- Jeff

Re: Outbound Route Filtering (ORF) vendor support

[Jeffrey Haas]

ORFs are a challenging feature and haven't gotten a lot of deployment for a 
number of reasons.

At a high level, they're a very coarse filter.  Since each new ORF type adds to 
the logical AND condition, you start having to be more and more permissive in 
what you permit in the policy.  Since a significant amount of common ISP 
policies require matching things in tuples, this doesn't translate super well 
into many types of automatically generated ORFs.

The ext-community-orf feature was effectively supplanted by Rt-Constrain (RFC 
4684).

The as-path ORF was challenging because different vendors have different ideas 
about what "regex" means and what the input tokens are.  Consider for example 
Juniper vs. Cisco regex matching.  The abstract fix would have been to define a 
regex that is for the feature.  I half suspect if people pushed on this these 
days, they'd want PCRE. :-)

The RD-ORF work is part of some ongoing discussion about how to deal with VRF 
overwhelm (prefix-limit exceed).

-- Jeff (IDR co-chair)

> On Aug 18, 2021, at 1:10 PM, Douglas Fischer  wrote:
> 
> Hello!
> 
> I also found a recent draft(expires Novembre 2021) about using Route 
> Distinguisher as a Value on ORF.
> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ 
> 
> 
> 
> 
> 
> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
> mailto:humbertogal...@gmail.com>> escreveu:
> Hi,
> 
> Is anyone aware of any vendor that supports Outbound Route Filtering
> (ORF) based on anything other than prefix-lists?
> 
> I found these two old IETF drafts (both expired :-/) which supported
> the idea of filtering based on community and as-path respectively, but
> I wasn't able to understand if they were ever discussed at the WG and
> if there was any outcome of the discussion (I suspect the authors are
> no longer even working with the mentioned companies in the drafts):
> 
> - https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02 
> 
> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13 
> 
> 
> Any info is very much appreciated.
> 
> Thanks,
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

[Jeffrey Haas]

> On Oct 21, 2019, at 4:17 PM, Brandon Martin  wrote:
> 
> On 10/21/19 3:37 PM, Jeffrey Haas wrote:
>> BGP over ipsec works fine.  But that said, it's mostly done with pre-shared 
>> keys.
> 
> Is anybody actually doing it in practice?

Absolutely.  In the SP sector?  Less clear.

>> The ugly issue of ipsec is that the ecosystem really wants IKE to do the 
>> good things people associate with long lived sessions.  I don't even vaguely 
>> pretend to be an ipsec/ike expert, but the wrangling over this and router 
>> bootstrapping issues generated a lot of heat and a small amount of light in 
>> IETF a while back.
> 
> Yes.  ipsec (IP layer) itself isn't too bad.  IKE is a complex mess.  A 
> functional mess, perhaps, but a mess nonetheless.  I'd really like to hear 
> from someone actually qualified on the cryptography side of things to chime 
> in on whether long-lived symmetric keys are even really a problem anymore.  
> If they're not, just generating a decent "session" key and statically 
> defining an SPI is a lot more straightforward.

I'm not someone qualified, but I'll regurgitate what I've distilled from past 
conversations with those who are. :-)

Presuming your key is strong enough, it may be infeasible to break it in a time 
that's of interest to the parties involved.  The primary issue is the usual 
issue of trying to keep anything secret: eventually disclosure becomes an 
issue.  And if you have no procedure for periodically updating your keys, it 
becomes a problem.

The problem is exacerbated by the fact that inter-provider key sharing is a 
PITA.  If you're having situations where you have to hit this list as a NOC of 
last resort, now try to imagine a regular cadence of conversations to update 
your key.  And then deal with the fact that key rotation for TCP-MD5 can be hit 
or miss.  In practice, this means that if you had someone that knew your keys 
and was kicked out of your company, they have the ability to do bad stuff.

The ability to more easily update your session keys is one of the big wins for 
tcp-ao.

A lot of the issues behind transport security are mitigated - and this is a 
point I end up raising to various IETF security reviewers on a regular basis 
when talking about control plane protocols:
- It's possible to reduce the attack surface by using things like GTSM.  You've 
acquired the key somehow?  Great - now get packets to that link.
- Similarly, protecting the link itself through things like MACSEC is a way to 
reduce the attack surface.
- What are the actual attacks they can do?  For BGP, knocking over the session 
is often the goal.  The necessary man in the middle for an active hijack if you 
can insert yourself into the conversation is absolutely doable... but you're 
better off just hijacking a router through another compromise and then simply 
injecting bad routing data.

Where much of this puts us is iBGP is of far more interest to an active 
attacker.  Protection of internal routing infrastructure, including firewalls 
that are properly configured, again can help here.  And this becomes even more 
tasty if you're in an environment making use of SDN-ish stuff.


> 
> OSPFv3 hopefully taught people some lessons with its initial lack of built-in 
> authentication.  "Just use ipsec".

This one, IMNSHO, can be blamed on specific IETF religion at the time.  The 
fallouts around this are one of my more favored examples of "this needed 
operational review".
> 
>> And if you have a rather scaled out router, imagine the cpu melting that 
>> goes with a cold startup scenario where you have to get all of those IKE 
>> sessions up to start up your BGP.  Now think what that does to your restart 
>> time. 
> 
> Indeed, though I've seen a trend toward putting rather hefty CPUs on the 
> control planes of "real" routers, nowadays, which I guess is welcome.  It 
> doesn't really contribute much to the overall cost of something that can push 
> 100s of Gbps in hardware, anyway.

Believe me, implementors are happy to have some extra cycles available.  
However, too many target platforms are either still under-powered or have 
operational requirements that push them toward slower CPUs.  

And even for large enough platforms, security computation can eat every spare 
cycle you have.  Generally, a conversation with crypto experts will eventually 
devolve to "key lengths/cipher is now considered weak, use the next one" - 
which is shorthand for saying "if you have available cpu, you're not using 
strong enough crypto". :-)

-- Jeff

Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

[Jeffrey Haas]

> On Oct 21, 2019, at 3:25 PM, Brandon Martin  wrote:
> 
> On 10/21/19 11:30 AM, Keith Medcalf wrote:
>> Why cannot one just put the MD5 authenticated connection inside a TLS 
>> connection?  What is the advantage to be gained by replacing the 
>> authentication mechanism with weaker certificate authentication method 
>> available with TLS?
> 
> Self-issued certificates with either CA pinning or end-certificate hash 
> pinning is arguably more secure than a shared passphrase as used by TCP-MD5 
> in that someone with knowledge of the secrets of one end cannot use it to 
> impersonate the other end whereas a shared passphrase is inherently shared 
> and symmetric in that respect.  Whether that really provides much value in 
> the context of a BGP session is perhaps questionable.

Considering a lot of hand-wringing from the various security conscious folk is 
over the ability to easily re-key, I think it mostly just complicates things.  
Certs are effectively a much nicer single use key.  Exactly how the cert 
lifetime interacts with peering sessions is likely to be several flavors of 
ugly.

> 
> Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations 
> and difficulty of configuration aside)?  It would also solve the TCP-RST 
> injection issues that TCP-MD5 was intended to resolve.  You can use null 
> encryption with ESP or even just AH if you want authentication without 
> confidentiality, too.  Or are we all going to admit that ipsec is almost dead 
> in that it's just too darned complex?  Just run BGP over TCP as normal and 
> install a security policy that says it must use ipsec with appropriate 
> (agreed-upon) authentication.  "Just", right?

BGP over ipsec works fine.  But that said, it's mostly done with pre-shared 
keys.

The ugly issue of ipsec is that the ecosystem really wants IKE to do the good 
things people associate with long lived sessions.  I don't even vaguely pretend 
to be an ipsec/ike expert, but the wrangling over this and router bootstrapping 
issues generated a lot of heat and a small amount of light in IETF a while back.

And if you have a rather scaled out router, imagine the cpu melting that goes 
with a cold startup scenario where you have to get all of those IKE sessions up 
to start up your BGP.  Now think what that does to your restart time. 

-- Jeff

Wide BGP Communities update (-04) - input solicited

[Jeffrey Haas]

The authors of the Wide BGP Communities Internet-draft would like to solicit
your feedback on the current version of the draft.  The intended purpose of
the feature is to provide for next-generation BGP communities.

Why next-generation?  A few motivations:
- BGP Path Attribute code space is limited.  We want to stop burning new
  code points for such features when the underlying mark a route behavior
  is the same.
- Each time we add something with new encoding, we get deployment lag from
  needing new code to handle it.
- While it's done the job for a number of years, existing communities force
  operators to go through a lot of convoluted policy to do anything from
  very common things to subtle things.

The accompanying use case document will be updated soon, but not prior to
the upcoming IETF.  Most of our attention the last few weeks has been on
getting the details of the encoding right.

In recognition to a very common use case desired here, note Section 5.  A
wide community is being registered with no further semantics than here's a
list of AS numbers.  This permits the desired AS4:AS4 semantic.

-- Jeff

- Forwarded message from internet-dra...@ietf.org -

Date: Thu, 13 Feb 2014 12:55:54 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-raszuk-wide-bgp-communities-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Wide BGP Communities Attribute
Authors : Robert Raszuk
  Jeffrey Haas
  Andrew Lange
  Shane Amante
  Bruno Decraene
  Paul Jakma
  Richard A Steenbergen
Filename: draft-raszuk-wide-bgp-communities-04.txt
Pages   : 24
Date: 2014-02-13

Abstract:
   Route tagging plays an important role in external BGP [RFC4271]
   relations, in communicating various routing policies between peers.
   It is also a very common best practice among operators to propagate
   various additional information about routes intra-domain.  The most
   common tool used today to attach various information about routes is
   through the use of BGP communities [RFC1997].

   Such information is important to allow BGP speakers to perform some
   mutually agreed actions without the need to maintain a separate
   offline database for each tuple of prefix and associated set of
   action entries.

   This document defines a new encoding which will enhance and simplify
   what can be accomplished today with the use of BGP communities.  The
   most important addition this specification makes over currently
   defined BGP communities is the ability to specify, carry as well as
   use for execution an operator's defined set of parameters.  It also
   provides an extensible platform for any new community encoding needs
   in the future.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

- End forwarded message -

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

Martin,

On Wed, Feb 05, 2014 at 10:06:31AM +0100, Martin Pels wrote:
  Wide communities is the wrong tool here. You want this:
  http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06
 
 This draft does not cater for the use case of describing a 32-bit ASN peering
 with a 32-bit route server, which would require a 4-byte Global Administrator
 as well as a 4-byte Local Administrator sub-field.

I think that's the first clear articulation I've read about why some people
want wide comms vs. a simple replacement for existing regular communities as
extended communities.  Thanks.

Wide comms can do that, but they're intended to be a somewhat bigger hammer.

This case is probably worth chatting with the authors and others in IDR at
IETF to see if we should do something simpler.

-- Jeff

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote:
 
 On Feb 5, 2014, at 8:52 AM, Jeffrey Haas jh...@pfrc.org wrote:
 
  This draft does not cater for the use case of describing a 32-bit ASN 
  peering
  with a 32-bit route server, which would require a 4-byte Global 
  Administrator
  as well as a 4-byte Local Administrator sub-field.
  
  I think that's the first clear articulation I've read about why some people
  want wide comms vs. a simple replacement for existing regular communities as
  extended communities.  Thanks.
 
 I suspect the operator confusion is that?s how they?ve been using 16-bit ASNs
 all along, so how did the IETF end up with something different.
 
 http://www.onesc.net/communities/ is a fairly comprehensive list of how they 
 are used today.

Thanks for the list.  Browsing the first several entries somewhat supports
the reason why I'm acting surprised.  While there are some cases where the
right hand side of the community is an AS number, a significant amount of it
was either an arbitrary value or something more structured.

The generic 4-byte draft I'm part of is intended to be low hanging fruit.
We don't need to deploy a new attribute, the format specifier is already
present in code.  All that was needed was a code point to say go use this
like existing RFC 1997 comms.  

The wide comms draft (and flex comms, where some of the ideas were pulled in
from) was intended to address the messier case where the meaning of a
community was already structured.  To pick on one of the items in the list:
http://www.onesc.net/communities/as209/

Coding these using regexes is a PITA, both as an implementor of the
underlying policy and as a sender who has to remember what the magic value
means.  Ideally the operator should end up with something simple: 
Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc.
Right now, these things are magic values.

The last few rounds of wide comms were attempts to get encoding formats in
place that accommodated some amount of grouping logic 
(peer-class CUSTOMER  North America, e.g.).  We did manage to work out a
way to do that encoding correctly.  But it turned out that the real killer
was transitive manipulation - you can't meddle with such a thing without
breaking logic.  So, back to a simpler drawing board.

An update to the wide-comm draft should be out by end of this week.  We'd
welcome some constructive criticism on it.

-- Jeff

[iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, Technical Considerations for Internet Service Blocking and Filtering]

[Jeffrey Haas]

It's IETF stuff.  Operator sanity check would probably be appreciated. :-)

-- Jeff

- Forwarded message from IAB Chair iab-ch...@iab.org -

Date: Wed, 29 Jan 2014 11:16:56 -0500
From: IAB Chair iab-ch...@iab.org
To: IETF Announce ietf-annou...@ietf.org
Cc: IAB i...@iab.org, IETF i...@ietf.org
Subject: Call for Review of draft-iab-filtering-considerations-06.txt, 
Technical Considerations for Internet Service Blocking and Filtering

This is a call for review of Technical Considerations for Internet
Service Blocking and Filtering prior to potential approval as an
IAB stream RFC.

The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/

The Call for Review will last until 26 February 2014.
Please send comments to i...@iab.org. 

On behalf of the IAB,
  Russ Housley
  IAB Chair

- End forwarded message -

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

Sent from my iPad

 On Jan 25, 2014, at 1:37 PM, Nick Hilliard n...@foobar.org wrote:
 
 On 25/01/2014 15:48, Sebastian Spies wrote:
 To make things worse: even if the IXPs ASN is 2-byte, I would assume,
 that RS implementors chose to interpret extended community strings as
 always being in the format 4-byte:2-byte (see RFC5668).
 
 some ixp operators (e.g. me) are rather enthusiastic about the idea of a
 modified form of draft-raszuk-wide-bgp-communities getting more traction.
 This would solve this particular problem and many others.
 

Wide communities is the wrong tool here. You want this:
http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06

-- Jeff 

 Nick
 

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

Sent from my iPad

On Jan 25, 2014, at 5:50 PM, Randy Bush ra...@psg.com wrote:

 http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03
 To me, that draft looks hugely complicated, like everything you
 could possibly think of was thrown in.
 
 aol
 
 do we have a chat with robert or push an alternative so that the wg is
 pushed to compromise?
 

The token to simplify is currently mine. The messy bit was an attempt to try to 
push policy algebra into the packet format. A hallway conversation with a 
certain German gentleman helped disabuse me about the wisdom of doing that. 

Cleaning up the document will take probably another two rounds but a terse 
description of where it should be going is template based structured 
communities. 

-- Jeff


 randy

[Idr] Configuration objects in BGP MIB v2: Call for consenus

[Jeffrey Haas]

Please pardon this intrusion in the usual operational chatter.

I have been working on the successor to the BGP MIB within IETF over the
last several years.  As part of a review of the current draft of this
MIB (http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-07) I have
been requested to gather operational consensus regarding being able to
configure your BGP peering sessions from within the MIB.  Please see the
forward below for the details.

The BGP MIBv2 is attempting to address some operational holes with
regards to the current BGP MIB.  These issues include IPv6 support and
also better counters for your peering session.  In addition to feedback
on the configuration objects issue I'd appreciate general feedback on
the MIB on or off the list.

My goal is to resolve all remaining open issues with the MIB within the
next few months and get it into working group last call.  A reference
implementation in Quagga will likely follow.

-- Jeff

- Forwarded message from Jeffrey Haas [EMAIL PROTECTED] -

Date: Sun, 6 Jul 2008 21:50:00 -0400
From: Jeffrey Haas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Idr] Configuration objects in BGP MIB v2: Call for consenus

Working Group,

Back around 2005 I had a number of discussions with people who had
provided input for the BGP MIBv2 work.  These conversations were
specifically regarding the configuration objects in the MIB.
draft-ietf-idr-bgp4-mibv2-05 was the last version of the MIB that
contained the proposed configuration objects.

The results of those discussions were effectively that the configuration
mechanisms in that MIB were too complex and had some potential issues.
In particular:

- Modern BGP implementations tend to be more complex than the feature
  set covered by the proposed MIBs.  It was not possible to
  configure all session specific features from the MIB.  Since the base
  MIB is not intended to cover all possible current and future features
  this is problematic.
- Configuration of peering sessions are not sufficient to fully
  implement BGP in an operational network.  BGP fundamentally requires
  policy for the population of the Ribs.  Policy elements and algebra
  vary considerably among vendors.  

  Providing a general policy engine for BGP in the MIB is likely out of
  scope of this work.

Presume that the structural issues from draft-05 may be addressed.
Should they be addressable, do we wish to pursue including configuration
objects in the BGP MIB?

Given the operational impact of this issue, I would appreciate it if
this call for consensus was distributed within and without IETF.  I will
be forwarding this to NANOG as a first step.

-- Jeff