Subject: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs

From: Jeff Haas <[email-masked]>
Date: Mon, 9 Jan 2012 12:40:19 -0800

I am the current editor for the BGP MIB (draft-ietf-idr-bgp4-mibv2).  I've been approached recently about MIB representation of BGP Multicast VPNs (draft-ietf-l3vpn-2547bis-mcast-bgp).  After having spent some time discussing this with some people internally at Juniper, it seems like the BGP MIBv2 would handle a significant portion of representing MVPNs.  This is great, because much of the purpose of the structure of the new BGP MIB was to make it re-usable for other address families.

The one sticking point is the representation of MVPN reachability (prefixes, effectively).  The BGP MIB does the following:

    bgp4V2NlriPrefixType OBJECT-TYPE
        SYNTAX     InetAddressType
        MAX-ACCESS not-accessible

        STATUS     current
        DESCRIPTION
            "The type of the IP address prefix in the
             Network Layer Reachability Information field.
             The value of this object is derived from the
             appropriate value from the bgp4V2NlriAfi field.
             Where an appropriate InetAddressType is not
             available, the value of the object must be
             unknown(0)."
        ::= { bgp4V2NlriEntry 4 }

    bgp4V2NlriPrefix OBJECT-TYPE
        SYNTAX     InetAddress
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "An IP address prefix in the Network Layer
             Reachability Information field. This object
             is an IP address containing the prefix with
             length specified by bgp4V2NlriPrefixLen.
             Any bits beyond the length specified by
             bgp4V2NlriPrefixLen are zeroed."
        REFERENCE
            "RFC 4271, Section 4.3<http://tools.ietf.org/html/rfc4271#section-4.3>."
        ::= { bgp4V2NlriEntry 5 }

    bgp4V2NlriPrefixLen OBJECT-TYPE
        SYNTAX     InetAddressPrefixLength
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "Length in bits of the address prefix in
             the Network Layer Reachability Information field."
        ::= { bgp4V2NlriEntry 6 }

It would seem that the "relatively simple" method to extend this to MVPN would be to update the InetAddress(Type) textual conventions.

I am aware that by making that statement I have stepped into the dragon's maw.  Please be gentle. :-)

But more seriously, this seems to be a good fit for what this TC was intended to accomplish: Make MIB structure more generic and reusable.  How could we go about accomplishing the goal of re-using the BGP MIB for MVPN?

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2012 00:40:12 +0100

> But more seriously, this seems to be a good fit for what this TC was intended to accomplish: Make MIB structure more generic and reusable.  How could we go about accomplishing the goal of re-using…

I have no clue what change you think is needed. Please excuse my
ignorance of BGP Multicast VPNs - but for me it is easier to
understand what you propose to change if there is a more concrete
description of the change you envision.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jeff Haas <[email-masked]>
Date: Mon, 9 Jan 2012 16:05:55 -0800

Juergen,

> description of the change you envision.

Reference:
http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-08

BGP MVPN routes are basically 7 types of routing information distributed in BGP as prefixes.  Some of these routes are effectively fixed length but that's a minor detail.  Please refer to section 4 for the different route formats to avoid significant copy and paste.

My proposal is that 7 code points are allocated for MVPN routes for InetAddressType for these 7 types of information.  Textual conventions would be defined to cover each of the appropriate types.

One small annoyance is that the DISPLAY-HINT syntax isn't quite flexible enough to cover the variable-length types in a fully pleasing format.  There's not much we can do about that.

If this proposal seems to have merit and would be likely to get traction, we'll submit some text for the MIB.

-- Jeff

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Jan 2012 11:52:41 +0100

Jeff,

I think that it would be useful however to provide an example of the
extensions that you have in mind, even if it's sketchy and not
syntactically perfect. I think that you are talking about extending the
InetAddressType TC with new values in order to use the BGPv2 MIB 'as
is', but I may be wrong. Putting more complexity in one of the most
commonly used set of TCs does not come for free either. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jeff Haas
> Sent: Tuesday, January 10, 2012 2:06 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast
> VPNs
> 
> Juergen,
> 
> BGP MVPN routes are basically 7 types of routing information
> distributed in BGP as prefixes.  Some of these routes are effectively
> fixed length but that's a minor detail.  Please refer to section 4 for
> the different route formats to avoid significant copy and paste.
> 
> My proposal is that 7 code points are allocated for MVPN routes for
> InetAddressType for these 7 types of information.  Textual conventions
> would be defined to cover each of the appropriate types.
> 
> One small annoyance is that the DISPLAY-HINT syntax isn't quite
> flexible enough to cover the variable-length types in a fully pleasing
> format.  There's not much we can do about that.
> 
> If this proposal seems to have merit and would be likely to get
> traction, we'll submit some text for the MIB.
> 
> -- Jeff
> 
> _______________________________________________
> IETFMIBS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietfmibs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2012 11:54:33 +0100

> If this proposal seems to have merit and would be likely to get traction, we'll submit some text for the MIB.

What I see in section 4 of draft-ietf-l3vpn-2547bis-mcast-bgp-08 does
not seem to be Internet addresses. There are quite a number of MIB
modules using InetAddressType and InetAddress and pretty much for all
of them these additions likely do not make sense. So either I do not
understand the proposal yet or if I understand it correctly, I tend to
not like it.

/js

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Jan 2012 07:58:21 -0500

Hi Juergen,

> understand the proposal yet or if I understand it correctly, I tend to

I suspect that Jeff wants to introduce 7 new values for InetAddressType
that allows him to represent these seven types of routes:

     + 1 - Intra-AS I-PMSI A-D route;
     + 2 - Inter-AS I-PMSI A-D route;
     + 3 - S-PMSI A-D route;
     + 4 - Leaf A-D route;
     + 5 - Source Active A-D route.
     + 6 - Shared Tree Join route;
     + 7 - Source Tree Join route;

I would have to see a more concrete proposal, but it seems a unwieldy
given that each of the above types could occur for both IPv4 and IPv6
addresses.  So that would require more than seven new values for
InetAddressType.  Unless I am not understanding the referenced draft
correctly...

Regards,
Brian

---

From: Jeff Haas <[email-masked]>
Date: Tue, 10 Jan 2012 06:28:09 -0800

Brian,

Since your response is closest to my intentions, I'll answer here:

On Jan 10, 2012, at 7:58 AM, Brian Haberman wrote:
> correctly…

You and Juergen are understanding this perfectly fine.

Also, as I expected, you're all not very fond of the idea (using differing wording in the various responses, but it's clear).  That saved having the discussion complicated by providing sample SMI.

What this means is, as the editor of the BGP MIB, I now have to ask and answer a slightly different problem.  I made use of the InetAddress MIB so that we could take advantage of the flexibility to cover both IPv4 and IPv6 reachability for our peering sessions as well as our prefixes.  However, BGP is capable of carrying more reachability than simply IPv4 or IPv6; in the example case, it's MVPN.  We also support things like VPLS.

This seems to suggest that BGP needs to copy and fork InetAddressType/InetAddress (and perhaps the prefix length TC as well) for a BGP specific MIB that can accommodate non-IP prefixes.

I would love an alternate suggestion to doing this since I do not relish the idea of maintaining such a TC MIB indefinitely. :-)

(I also understood that was exactly what I was asking the owners of INET-ADDRESS-MIB to do.)

One property such a BGP-specific MIB should have is to use the same code points as the INET-ADDRESS-MIB where possible.  This would enable code re-use.

Is my logic correct?

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jan 2012 15:41:09 +0100

> One property such a BGP-specific MIB should have is to use the same code points as the INET-ADDRESS-MIB where possible.  This would enable code re-use.

If the reachability info BGP is carrying turns out to be BGP specific,
then having a BGP specific TC to represent it seems quite OK. Is any
non-BGP protocol using the formats and the encodings I looked at
earlier this morning? If not, these formats seems to be rather BGP
specific.

/js

---

From: Jeff Haas <[email-masked]>
Date: Sat, 14 Jan 2012 08:16:39 -0800

Juergen,

> earlier this morning? If not, these formats seems to be rather BGP

It seems that I will be authoring (and probably maintaining) another BGP TC MIB for this purpose.

Could the group share any experiences with MIB documents that note code points by reference?  The BGP protocol suite continues to evolve at a very steady pace and it would be nice if I could point to new code points at IANA rather than having a MIB document that could never be stable enough to really reach an RFC, except perhaps for a snapshot.

-- Jeff

---

From: "Joan Cucchiara" <[email-masked]>
Date: Sat, 14 Jan 2012 13:06:14 -0500

Hi Jeff,

If you are asking how to go about asking IANA to create a name space, the 
MIB Guidelines
doc discusses this.

http://www.rfc-editor.org/rfc/rfc4181.txt

MIB guidelines also discusses how MIB docs can add new values to these IANA 
maintained TCs.

I don't see the  point in having IANA maintain a TC-MIB, which is never used 
in an
actual RFC MIB.  While this might be easier for you, there is still work by 
someone.
Typically, the IANA considerations section that requests creating a new name 
space,
is included in a MIB document that is advancing to RFC status.   I don't 
know of  acceptions, but
maybe someone else does?

Thanks,
  -Joan

----- Original Message ----- 
From: "Jeff Haas" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, January 14, 2012 11:16 AM
Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs

> Could the group share any experiences with MIB documents that note code 
> points by reference?  The BGP protocol suite continues to evolve at a very 
> steady pace and it would be nice if I could point to new code points at 
> IANA rather than having a MIB document that could never be stable enough 
> to really reach an RFC, except perhaps for a snapshot.
>
> -- Jeff
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 15 Jan 2012 11:49:22 +0100

> Could the group share any experiences with MIB documents that note code points by reference?  The BGP protocol suite continues to evolve at a very steady pace and it would be nice if I could point…

I do not know what "note code points by reference" means. You can
place a whole TC MIB module under IANA control if extensions are
needed and a WG process is to heavy weight.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 15 Jan 2012 15:02:23 +0100

> Sent: Saturday, January 14, 2012 6:17 PM
> points by reference?  The BGP protocol suite continues to evolve at a
> very steady pace and it would be nice if I could point to new code
> points at IANA rather than having a MIB document that could never be
> stable enough to really reach an RFC, except perhaps for a snapshot.
> 
> -- Jeff
> 

Hi Jeff,

Do you refer to the IANA maintained MIB modules listed at
http://www.iana.org/protocols? The policy for extending each of the
modules is defined typically in the RFC where the TC is defined. If for
example 'Expert Review' (as the policy is for many of these) IANA passes
the requests to the expert designated by the IESG, who is evaluating and
advising IANA. I think that the process is well known and works pretty
well, but other people are invited to share their experiences. 

Dan

---

From: Jeff Haas <[email-masked]>
Date: Tue, 17 Jan 2012 06:34:04 -0800

Dan, Juergen, Joan,

Thanks for your kind responses.

On Jan 15, 2012, at 9:02 AM, Romascanu, Dan (Dan) wrote:

This was exactly the sort of thing I was looking for.  It avoids my problem of a never-really-published MIB that is constantly being updated for the BGP MIBv2.

Joan had written earlier:

Please recall that the purpose of this is to help make the BGP MIBv2 (which is standards track) be more generally useful for BGP address families.

If your point was that an initial MIB document is required to bootstrap the request for IANA to maintain a TC MIB per RFC 4181, that's understandable.

-- Jeff

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 17 Jan 2012 10:02:15 -0500

Jeff,

Could you remind me again what the requirements are by the the IDR WG to 
have
a document advance to RFC status?   As I recall, this is more involved than 
what is required by
other WGs.

Could you also tell us what the status is of the BGPv2 MIBs with respect to 
the
IDR WG requirements?

Thank you,
  -Joan

----- Original Message ----- 
From: "Jeff Haas" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 17, 2012 9:34 AM
Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs

> This was exactly the sort of thing I was looking for.  It avoids my 
> problem of a never-really-published MIB that is constantly being updated 
> for the BGP MIBv2.
>
> Please recall that the purpose of this is to help make the BGP MIBv2 
> (which is standards track) be more generally useful for BGP address 
> families.
>
> If your point was that an initial MIB document is required to bootstrap 
> the request for IANA to maintain a TC MIB per RFC 4181, that's 
> understandable.
>
> -- Jeff
>

---

From: Jeff Haas <[email-masked]>
Date: Tue, 17 Jan 2012 07:45:57 -0800

> a document advance to RFC status?   As I recall, this is more involved than 

Two independent implementations.

> Could you also tell us what the status is of the BGPv2 MIBs with respect to 

Stable, but lacking implementation of the latest draft.  Juniper has an enterprise MIB implementation of the older draft but I haven't had the opportunity to update the implementation since joining.  (MIBs get poor attention from product managers in general.)  Another large vendor is rumored to have an implementation in progress.

I also had most of an implementation in Quagga that I have yet to complete.  The majority of my problem was net-snmp issues with notifications, particularly with sysUpTime timestamps.
I probably should complete that just to push the standard.

-- Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Jan 2012 18:48:49 -0000

Hi,

The "two implementations" rule is imposed on a case-by-case basis by the IDR WG
chairs. It is usual for protocol modifications to BFD.  I am not aware of it
being enforced for MIB modules (indeed, I am not sure what would be meant by
"two interoperating independent implementations" of a MIB module).

Let's allow the WG chairs to decide what is needed in this case.

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jeff Haas
> Sent: 17 January 2012 15:46
> To: Joan Cucchiara
> Cc: [email-masked]
> > the IDR WG requirements?
> Stable, but lacking implementation of the latest draft.  Juniper has an
enterprise
> MIB implementation of the older draft but I haven't had the opportunity to
> update the implementation since joining.  (MIBs get poor attention from
product
> managers in general.)  Another large vendor is rumored to have an
> implementation in progress.
> 
> I also had most of an implementation in Quagga that I have yet to complete.
The
> majority of my problem was net-snmp issues with notifications, particularly
with
> sysUpTime timestamps.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 18 Jan 2012 12:32:58 +0100

> I am not sure what would be
> meant by

Roughly - the method used by the WGs developing MIB modules was to test
(at least) two independent implementations of agents and two
implementations of manager applications, run (at least) a complete MIB
walk on the respective MIB module and make sure that the results
obtained by the two applications from the two agents are consistent. 

Regards,

Dan

> Behalf Of Adrian Farrel
> Sent: Tuesday, January 17, 2012 8:49 PM
> To: 'Jeff Haas'; 'Joan Cucchiara'
> Cc: [email-masked]
> Behalf