Subject: [Idr] 4byte ASN support in RFC4273

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 22 Aug 2006 11:06:35 +0200

IDR List,

RFC4273 says:

  bgpPathAttrASPAth OBJECT-TYPE
    SYNTAX OCTET STRING (SIZE (2..255))
    [...]
    EAch AS is represented as a pair of octets according to the following
    algorithm:
      first-byte-of-pair = ASNumber / 256
      second-byte-of-pair = ASNumber & 255;

And similar for bgp4PathAttrASPathSegment.

Question: what will happen when 4byte ASN are deployed?  Can I just
replace the Octet string by 4 octets (ASN/(265^3), ASN/(256^2), ASN/256,
ASN%255) (and assume that things will continue to work)?   Or does this
need an update of the RFC?

The same RFC says:

   bgpPeerRemoteAs OBJECT-TYPE
     SYNTAX  Integer32 (0...65535)

Same question.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400 + 381600 = 1160820000.    

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Thomas E. Spanjaard" <[email-masked]>
Date: Tue, 22 Aug 2006 10:23:19 +0000

> need an update of the RFC?

I think draft-ietf-idr-as4bytes-12.txt states that the ASPath should 
only be interpreted as 4-octet AS numbers when your peer advertises the 
4byte AS capability and the other peer does so as well. Otherwise, it 
should interpret the AS_PATH as 2-octet AS numbers.

>     SYNTAX  Integer32 (0...65535)

The 4-octet AS number of the NEW BGP peer is 'advertised' as the 
Capability Value of the Capability Optional Parameter of the Four-octet 
AS Number Capability, sized 4 octets (or if you will, an unsigned 32bits 
integer). The 2-octet AS to use by 4-octet AS peers is AS_TRANS, which 
is defined by IANA.

Cheers,
-- 
         Thomas E. Spanjaard
         [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Aug 2006 12:43:21 -0400

>     SYNTAX  Integer32 (0...65535)

Answer: New MIB needed.  BGP MIBv2, as previously published, didn't
get a lot of support from people due to excess complexity.  At
the request of the WG chairs, I've factored a lot of that complexity out.

Unfortunately, I'm stuck on getting functional conformance statements
for it.  Once I have those compiling, I have several drafts to publish.

-- Jeff

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 23 Aug 2006 18:11:11 +0200

Jeff,

>for it.  Once I have those compiling, I have several drafts to publish.

Are you planning to write this draft/MIB?  I have several products using
the current MIB and it'd really help if I could point maintainers to
a new MIB and ask them to upgrade?  I can even provide a list of things
that need to be changed (but I'm no MIB expert, so I don't think I
could write the MIB myself).

Henk

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Aug 2006 16:30:13 -0400

Henk,

On Wed, Aug 23, 2006 at 06:11:11PM +0200, Henk Uijterwaal wrote:
> Are you planning to write this draft/MIB?

A version of this mib was proposed:
draft-ietf-idr-bgp4-mib-v2-05 was the last version published.

It didn't receive much support due to its complexity.

I've factored the complex functionality out, removed configuration
objects and am planning no a republish of the components within
the next two weeks, work permitting.  Your review would be greatly
appreciated.

> I have several products using

Inputs on the MIB features would be appreciated.  Core features of
the base mib include:

- Support for multiple bgp instances
- Support for multiple route instances
- 4 byte as path support
- ipv6 support
- prefix counters
- hooks for extension mibs
  + communities
  + extended-communities
  + confederations
  + route reflect
  + etc.

Long term, this may also support other uses of bgp to transport non-ipv4/v6
nlri, but that isn't the focus of this work.

-- Jeff

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Aug 2006 07:54:30 +0300 (EEST)

> - hooks for extension mibs

Aren't we getting pretty close to the original 'too complex' MIB? 
Was there any indication which specific bits of the MIB were felt to 
be particularly complex.

As a particular item, as an operator I want to be able to see the 
prefix counts and, if at all possible, prefixes which are received 
over the BGP session but are filtered out in my configuration (e.g., 
prefix or AS path list).  The BGP-MIB-V2 added support for that I 
think.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 24 Aug 2006 15:20:59 +0200

Jeff,

>the next two weeks, work permitting.  Your review would be greatly

I read the draft this morning, mainly focussing on 4 byte ASN.  This
draft seems to do what we want (provide data about routing for our
monitoring stuff).  I cannot really comment on the complexity (or lack
thereof) of the entire MIB.

Henk

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Aug 2006 10:13:29 -0400

Pekka,

> Aren't we getting pretty close to the original 'too complex' MIB? 

For the most part, all BGP extentions are factored into separate MIBs.
If you don't want to see them, you don't have to.

> Was there any indication which specific bits of the MIB were felt to 

Configuration objects were specifically noted.

> prefix or AS path list).  The BGP-MIB-V2 added support for that I 

The MIB has kept the prefix counters for total in, total out and
accepted, rejected.  An implementation, depending on what it does
with a rejected prefix, may not be able to track rejected prefixes.

-- Jeff