Subject: RE: draft-ietf-mpls-tc-mib-06a.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 1 Oct 2003 16:49:57 +0200

> >Even if you did want it to be identifyable by 2 or 3 address types,
> >then I would create multiple "discriminated unions" by 
> >having multiple pairs of TeHopAddressType/TeHopAddress columns.
> 
> 	We could. OTOH, the text and objects that are 
> in the MIB now are described correctly, compile cleanly,
> and achieve the same thing, so I would rather leave
> things as they are than skin the cat yet another way
> if it is okay with you. 8)
> 
Sure... in C-code, you can do

  typedef struct und_union teHopAddress {
      int                 type;    /* enums for ip, as, unnum, lspid */
      unsigned char[256]  address; /* format depends on type */
  } TeHopAddress;

and then later one could do

  struct someTableEntry {
    /* index stuff  */
    TeHopAddres      address;
    unsigned char[4] as;     /* AS number if address.type is set to 'as' */
    unsigned char[4] unnum;  /* ifnumber if address.type is set to 'as' */
    unsigned char[6] lspId;  /* lspid if address.type is set to 'as' */
  }

Does that sound/look like good programming?
Well, I think not... but I have to admit that it was a few years
ago that I last wrote C-code  :-((

Bert
> 	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 1 Oct 2003 10:57:12 -0400

>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
>Sent: Wednesday, October 01, 2003 10:50 AM
>To: [email-masked]'; 'Mpls (E-mail)'
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; 'Joan 
>Cucchiara x302'; 'Kireeti Kompella'; [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]; [email-masked]
>Subject: RE: draft-ietf-mpls-tc-mib-06a.txt
>
>

	Whether it is great or not, I am not sure,
but the point is that there are cases where you need
more than one of those fields at the same time.
If that example hadn't been brought up, I agree
with you that a single union was okay. In fact, I
had originally been making this change when it
was pointed out that we shouldn't remove it
for the reasons I gave earlier.

	--Tom