The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Apr> msg00088



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Last Call MPLS-TC-MIB #6

  • From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
  • Date: Sat, 5 Apr 2003 16:23:12 +0200
  • Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, jcucchiara@artel.com, cheenu@paramanet.com, arun@force10networks.com, hans@ipunplugged.com, kireeti@juniper.net, mpls@UU.NET

Mike, the problem is that they want to use the TeHopAddressAS
in the TeHopAddress objects, and those are of type OCTET STRING,
so the one from RFC3291 cannot be used.

Maybe 3291bis should also add a OCTET-STRING based AsNumber?

Thanks,
Bert 

> -----Original Message-----
> From: Mike MacFaden [mailto:mrm@riverstonenet.com]
> Sent: zaterdag 5 april 2003 7:04
> To: Thomas D. Nadeau
> Cc: Wijnen, Bert (Bert); jcucchiara@artel.com; cheenu@paramanet.com;
> arun@force10networks.com; hans@ipunplugged.com; kireeti@juniper.net;
> mpls@UU.NET
> Subject: Re: Last Call MPLS-TC-MIB #6
> 
> 
> On Thu, Apr 03, 2003 at 11:05:52AM -0500, Thomas D. Nadeau wrote:
> >>6) TeHopAddressAS will most likely be a duplicate of
> >>whatever Jeffrey Haas does on the updates to the BGP mib modules.
> >>Should probably consult on this before we end up with TWO TCs
> >>that can be used to represent a 2 or 4 byte ASN.
> >
> >         The current state of these objects were as strongly
> >suggested by Bert and after numerous iterations including
> >the review from Atlanta. I hesitate to change them further unless
> >there is a serious flaw that you can identify. On the issue of
> >consistency with the BGP TCs, if the BGP guys want to reference
> >our TC,  then that is cool but we are not in a position at this
> >point to wait around to see what they want to do before we
> >change these TCs.
> 
> The new BGP MIB module draft-ietf-idr-bgp4-mibv2-03.txt uses
> the following TC from *RFC 3291* 
> 
> InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
>     STATUS      current
>     DESCRIPTION
>         "Represents an autonomous system number which identifies an
>          Autonomous System (AS). An AS is a set of routers under a
>          single technical administration, using an interior gateway
>          protocol and common metrics to route packets within the AS,
>          and using an exterior gateway protocol to route packets to
>          other ASs'. IANA maintains the AS number space and has
>          delegated large parts to the regional registries.
>  
>          Autonomous system numbers are currently limited to 16 bits
>          (0..65535). There is however work in progress to enlarge the
>          autonomous system number space to 32 bits. This textual
>          convention therefore uses an Unsigned32 value without a
>          range restriction in order to support a larger autonomous
>          system number space."
>     REFERENCE  "RFC 1771, RFC 1930"
>     SYNTAX      Unsigned32
>  
> 
> versus
> 
>   TeHopAddressAS ::= TEXTUAL-CONVENTION
>              STATUS      current
>              DESCRIPTION
>                 "Represents a two or four octet AS number.
>                  The AS number is represented in network byte
>                  order (MSB first).  A two-octet AS number has
>                  the two MSB octets set to zero."
>              SYNTAX      OCTET STRING (SIZE (4))
>  
> 
> I contend you can remove TeHopAddressAS. 
> 
> InetAutonomousSystemNumber
> a) Is much better described 
> b) Is easily imported from an existing RFC (bgp mib modules use it)
> 
> Thanks,
> Mike MacFaden
> 
>  
>