Subject: Handling multiple IP addresses on PPP interfaces with RSVP-TE

From: Bora Akyol <[email-masked]>
Date: Thu, 1 Feb 2001 10:35:26 -0800

I am kind of curiuos about what people are doing to handle
multiple IP addresses on PPP interfaces when they are
establishing LSPs with RSVP-TE?

Also, how are these multiple IP addresses per physical link
advertised in ISIS-TE or OSPF-TE?

I see not that much value in assigning multiple IP addresses
(paired) on PPP interfaces, but the fact that you can means that
both the IGPs and MPLS signaling must support it.

Thanks

Bora

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 2 Feb 2001 08:56:57 -0800 (PST)

Hi Bora,

> establishing LSPs with RSVP-TE?

As I see it, the ERO will have *one* of the multiple addresses on
the link.  However, RSVP must do admission control and bandwidth
accounting per *link*, not per *address*.

Is that what you meant?

> advertised in ISIS-TE or OSPF-TE?

IS-IS already specifies this:

5.2 Sub-TLV 6: IPv4 interface address

   This sub-TLV contains a 4-octet IPv4 address for the interface
   described by the (main) TLV.  This sub-TLV can occur multiple times.
...

5.3 Sub-TLV 8: IPv4 neighbor address

   This sub-TLV contains a single IPv4 address for a neighboring router
   on this link.  This sub-TLV can occur multiple times.

It behooves OSPF to say a few words on this subject, if for no other
reason than to keep up in the ISIS-OSPF arms race.

> both the IGPs and MPLS signaling must support it.

I don't see what changes are needed in signalling to handle this.

Kireeti.

---

From: Bora Akyol <[email-masked]>
Date: Fri, 2 Feb 2001 10:16:01 -0800

Kireeti> It behooves OSPF to say a few words on this
    Kireeti> subject, if for no other reason than to keep up in
    Kireeti> the ISIS-OSPF arms race.

Anyone from the OSPF land willing to take this on and comment on
whether we can advertise multiple IP addresses per interface
with TE extensions?

Bora

---

From: "Darek Skalecki" <[email-masked]>
Date: Tue, 06 Feb 2001 10:41:47 -0500

> whether we can advertise multiple IP addresses per interface

I am not from OSPF land :) and I don't have the latest version of the
OSPF TE Extensions draft handy but I recall a statement in the draft
indicating that each sub-TLV of the Link TLV may occur only once. Two of
such sub-TLVs are used to specify link addresses: localIfAddress and
remoteIfAddress. This implies that to advertise a link with multiple
addresses then multiple Link TLVs are needed which in turn implies that
other info specified in the Link TLV (b/w, color, metric) would need to
be duplicated, i.e. for a link with 5 addresses, 5 Link TLVs are needed
with the only difference between the Link TLVs being the addresses while
b/w, color and metric info would be the same. This is not an efficient
way to advertise info about multi-address links. The question to the
authors of OSPF TE Extensions draft therefore is whether the restriction
of "may occur only once" be lifted. This would bring OSPF TE Extensions
closer to the same extensions for ISIS (I believe the OSPF TE Extensions
were supposed to mirror exactly the extensions to ISIS).

In addition, the OSPF TE Extensions draft states that only a single Link
TLV may occur in an Opaque LSA of Type 10 implying multiple Opaque LSAs
for multiple Link TLVs. This again has a potential for a negative impact
to OSPF operation in particular flooding. The question therefore is
whether this restriction can also be lifted, i.e. Opaque LSA may carry
more than one Link TLV.

Unless these issues are resolved I can see operation of OSPF lag behind
the operation of ISIS with respect to TE extensions and multi-address
links. Please note that I am not trying to stir up yet another debate
about OSPF vs ISIS :).

Cheers,

Darek

--
Darek Skalecki
Nortel
(613) 765-2252

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Feb 2001 20:20:36 -0800 (PST)

> indicating that each sub-TLV of the Link TLV may occur only once.

As you say, lifting this restriction is the easy way out, and makes
OSPF compatible with ISIS.  Forthcoming.

> whether this restriction can also be lifted, i.e. Opaque LSA may carry

This is actually a Good Thing.  Why would this affect flooding negatively?
It would appear useful to decouple the flooding of independent TE links.

Kireeti.

---

From: Dave Katz <[email-masked]>
Date: Mon, 12 Feb 2001 23:56:31 -0800 (PST)

At one point in the life of the draft it allowed putting multiple chunks
of stuff into a single LSA, but John Moy was fairly adamant that LSAs
have the finest granularity possible, so that's what we ended up with.

   Date: Mon, 12 Feb 2001 20:20:36 -0800 (PST)
   From: Kireeti Kompella <[email-masked]>
   Cc: [email-masked], [email-masked], [email-masked], [email-masked],
	   [email-masked]

   Kireeti.

---

From: "Darek Skalecki" <[email-masked]>
Date: Tue, 13 Feb 2001 08:32:05 -0500

> This is actually a Good Thing.  Why would this affect flooding negatively?

Please correct me if I am wrong but there surely must be some extra overhead
(bandwidth, memory and CPU) if N LSAs with a single TLV are advertized versus
1 LSA with N TLVs.

> It would appear useful to decouple the flooding of independent TE links.

By removing the restriction of a single Link TLV per Opaque LSA does not
prevent one  from advertizing a single Link TLV per Opaque LSA if fine
granularity is required.

--
Darek Skalecki
Nortel
(613) 765-2252