Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Jan 2001 21:20:38 -0500

Tony, Henk,

Please change the following:

   If the interface being advertised for Traffic Engineering purposes is
   unnumbered, the first two octets of the IPv4 neighbor address sub-TLV
   are set to zero and the next two octets are set to the interface ID
   of the unnumbered interface. In combination with the IPv4 interface
   address sub-TLV this identifies the unnumbered link over which the
   advertised adjacency has been established.

Please specify that the first octet to be set to zero and the
remaining three octets contain the ifindex.  This will be consistent
with the specification and the practice in OSPF (yes, I know its an
ISIS doc) and it will also be much more convenient for big routers
with lots of interfaces that number their pseudo-interfaces with three
significant octets of numbering (like ours).

Curtis
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Bora Akyol <[email-masked]>
Date: Tue, 23 Jan 2001 20:12:45 -0800

Curtis

I was under the impression that ifindex was agreed to be 32 bits
long based on the discussion about 2-3 months ago on the MPLS
mailing list. Is there going to be an ID that clarifies this in
a consistent manner for all of us?

Bora

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:

    Curtis> Tony, Henk,

    Curtis> Please change the following:

    Curtis>    If the interface being advertised for Traffic
    Curtis> Engineering purposes is unnumbered, the first two
    Curtis> octets of the IPv4 neighbor address sub-TLV are set
    Curtis> to zero and the next two octets are set to the
    Curtis> interface ID of the unnumbered interface. In
    Curtis> combination with the IPv4 interface address sub-TLV
    Curtis> this identifies the unnumbered link over which the
    Curtis> advertised adjacency has been established.

    Curtis> Please specify that the first octet to be set to
    Curtis> zero and the remaining three octets contain the
    Curtis> ifindex.  This will be consistent with the
    Curtis> specification and the practice in OSPF (yes, I know
    Curtis> its an ISIS doc) and it will also be much more
    Curtis> convenient for big routers with lots of interfaces
    Curtis> that number their pseudo-interfaces with three
    Curtis> significant octets of numbering (like ours).

    Curtis> Curtis
    Curtis> _______________________________________________
    Curtis> Isis-wg mailing list - [email-masked]
    Curtis> http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Bora Akyol <[email-masked]>
Date: Tue, 23 Jan 2001 20:30:20 -0800

Let me clarify myself, ifindex was "agreed" (AFAIR) to be 32 bits long to
better accommodate SNMP. Our internal implementation uses 32
bits for ifindex for precisely this reason. If we have a 24 bit
ifindex for MPLS, this would be yet another table/hash/hack to
map between 32 bits and 24 bits. (Yes, I know there are
efficient hacks that can be done, but there is some interesting
properties that are associated with ifindices in SNMP like they
should not repeat, strict rules for deleting them which make
this somewhat more undesirable IMHO)

Of course if we increase the index to 32 bits then we need to
have another word to play with since we will at least need one
flag to distinguish between IP addresses and ifindices.

Bora

>>>>> "Bora" == Bora Akyol <[email-masked]> writes:

    Bora> Curtis I was under the impression that ifindex was
    Bora> agreed to be 32 bits long based on the discussion
    Bora> about 2-3 months ago on the MPLS mailing list. Is
    Bora> there going to be an ID that clarifies this in a
    Bora> consistent manner for all of us?

    Bora> Bora

    Curtis> Tony, Henk,

    Curtis> Curtis

    Bora> _______________________________________________
    Bora> Isis-wg mailing list - [email-masked]
    Bora> http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Jan 2001 09:56:17 -0500

> a consistent manner for all of us?

That breaks the OSPF rule that a leading octet of zeros indicates an
ifindex and non-zero leading octet indicates an address.  I argued for
3 significant bytes.

We can fit our ifindexes comfortably into 3 bytes even with reserving
bay/slot/port bit fields in the physical address portion of ifindex
space and doing fairly sloppy allocation in the vif space.

Do we really need 4 bytes?

If so, for most implementations the top byte will just happen to be
zero and if a customer does use OSPF the scheme for allocating ifindex
values won't break.  A particular large and important customer of ours
happens to use and prefer to use OSPF so I need to be concerned.

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Wed, 24 Jan 2001 10:32:02 -0800

4 bytes aligns well with SNMP ifindex, I can live with 3 bytes
as long as it is clear when we have an IP address vs ifindex.

My personal preference is that it is much better  to explicitly
identify the data type rather than infer it from the data
itself. 

typedef struct {
       bool is_ip_addr;
       uint32 if_identifier;
} if_identifer_t;

would be the most clear cut definition IMHO, but yes it does
waste 4 more bytes. On the other hand, in this day and age, do
we really care about 4 more bytes per TE TLV.

Either way, we should decide this and make sure that it is
consistent for ISIS, OSPF, ... .

Bora

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:

    Curtis> In message
    Curtis> <[email-masked]>, Bora
    Curtis> Akyol writes:
    >> Curtis
    >> 
    >> I was under the impression that ifindex was agreed to be
    >> 32 bits long based on the discussion about 2-3 months ago
    >> on the MPLS mailing list. Is there going to be an ID that
    >> clarifies this in a consistent manner for all of us?
    >> 
    >> Bora

    Curtis> That breaks the OSPF rule that a leading octet of
    Curtis> zeros indicates an ifindex and non-zero leading
    Curtis> octet indicates an address.  I argued for 3
    Curtis> significant bytes.

    Curtis> We can fit our ifindexes comfortably into 3 bytes
    Curtis> even with reserving bay/slot/port bit fields in the
    Curtis> physical address portion of ifindex space and doing
    Curtis> fairly sloppy allocation in the vif space.

    Curtis> Do we really need 4 bytes?

    Curtis> If so, for most implementations the top byte will
    Curtis> just happen to be zero and if a customer does use
    Curtis> OSPF the scheme for allocating ifindex values won't
    Curtis> break.  A particular large and important customer of
    Curtis> ours happens to use and prefer to use OSPF so I need
    Curtis> to be concerned.

    Curtis> Curtis

---

From: Bora Akyol <[email-masked]>
Date: Wed, 24 Jan 2001 12:39:17 -0800

Curtis

I agree with you that addition of another byte can be avoided
and still give us the ability to differentiate between ifindices
and IP addresses. On the other hand, the
question that I would like to ask the WG(s) is whether it is
worth it to add the **explicit** identification so that there
are no assumptions and no confusion.

As I said before, as long as this issue is settled and WG agrees on a
consistent representation method, we should be OK. If there is a
need for a different representation that was backwards
compatible, I sure hope that people would be receptive to that
later on.

Regards

Bora

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:

    Curtis> In message
    Curtis> <[email-masked]>, Bora
    Curtis> Akyol writes:
    >>  4 bytes aligns well with SNMP ifindex, I can live with 3
    >> bytes as long as it is clear when we have an IP address
    >> vs ifindex.
    >> 
    >> My personal preference is that it is much better to
    >> explicitly identify the data type rather than infer it
    >> from the data itself.
    >> 
    >> typedef struct { bool is_ip_addr; uint32 if_identifier; }
    >> if_identifer_t;
    >> 
    >> would be the most clear cut definition IMHO, but yes it
    >> does waste 4 more bytes. On the other hand, in this day
    >> and age, do we really care about 4 more bytes per TE TLV.
    >> 
    >> Either way, we should decide this and make sure that it
    >> is consistent for ISIS, OSPF, ... .
    >> 
    >> Bora

    Curtis> Bora,

    Curtis> About two paragraphs above the one I quoted it
    Curtis> advises you to put the router-id in place of the
    Curtis> near end address if the interface is unnumbered.
    Curtis> The paragraph I quoted tells you to put the ifindex
    Curtis> in place of the far end address if the interface is
    Curtis> unnumbered.

    Curtis> If the near end interface address is equal to the
    Curtis> router ID, we can assume that the far end is an
    Curtis> interface, but that relies on the ISP not forgeting
    Curtis> to set the router-id to the address of the loopback
    Curtis> device and not the address of an interface.  We can
    Curtis> also use the same test that is used in OSPF, if the
    Curtis> top octet is zero, its an ifindex but the draft
    Curtis> should advise against using ifindex values that do
    Curtis> not have all zeros in the top octet.

    Curtis> There is really no need to add a 5th byte just to
    Curtis> indicate if the value is a IP address of ifindex.

    Curtis> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Jan 2001 15:30:25 -0500

> consistent for ISIS, OSPF, ... .

Bora,

About two paragraphs above the one I quoted it advises you to put the
router-id in place of the near end address if the interface is
unnumbered.  The paragraph I quoted tells you to put the ifindex in
place of the far end address if the interface is unnumbered.

If the near end interface address is equal to the router ID, we can
assume that the far end is an interface, but that relies on the ISP
not forgeting to set the router-id to the address of the loopback
device and not the address of an interface.  We can also use the same
test that is used in OSPF, if the top octet is zero, its an ifindex
but the draft should advise against using ifindex values that do not
have all zeros in the top octet.

There is really no need to add a 5th byte just to indicate if the
value is a IP address of ifindex.

Curtis