Subject: Re: OSPFv3 Applications Support

From: Rohit Dube <[email-masked]>
Date: Tue, 4 Mar 2003 18:29:11 -0500

Folks,

This issue has been around for a while and it is time that
we picked one of the proposals as the WG document.

My read of the consensus is that
draft-ishiguro-ospf-ospfv3-traffic-01.txt
should be used as the basis for TE for OSPFv3.

Anybody care to comment further on the topic? Preferrably with
points that have not been discussed on the list before.

Regards,
--rohit.

On Thu, 9 Jan 2003 18:06:01 -0500 Acee Lindem writes:
=>Kunihiro Ishiguro wrote:
=>>>At the 55th IETF WG meeting, there were two proposals for
=>>>supporting additional OSPF applications. There was quite
=>>>a lively discussion of the relative merits of each and
=>>>we decided that it would be best to discuss it further on
=>>>the OSPF WG list. Heretofore, there hasn't been any further
=>>>discussion so I figure it is time to get the ball rolling (or
=>>>in this case, the E-mails flying).
=>>>
=>>>  - OSPFv2 Opaque LSAs in OSPFv3
=>>>    http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt
=>>>
=>>>  - Traffic Engineering Extensions to OSPF version 3
=>>>    http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-
>01.txt
=>>>
=>>>The first defines the transformations necessary to map OSPFv2
=>>>opaque LSAs to OSPFv3. The second defines how to map the most
=>>>widely implemented and deployed OSPFv2 opaque to OSPFv3 using
=>>>new LSA types.
=>>
=>>
=>> Well, besides I wrote a draft for OSPFv3 TE, I support defining a new
=>> LS type for new application.  OSPFv3 already has clean design and very
=>> flexible architecture for new application.
=>
=>[Speaking as WG member]
=>
=>I have to agree with you here. I can't see the point of adding another
=>layer of multiplexing for these types in OSPFv3. In OSPFv2, the opaque
=>type was necessary since unknown types weren't handled. From an
=>applications standpoint, it is much more likely that one is going to
=>want to do something (whether it be process or view) all the LSAs
=>associated with a given type than all opaque LSAs.
=>
=>The only additional cost that I see is that when an opaque type is
=>requested from IANA for OSPFv2, an OSPFv3 LSA type function code must
=>also be requested.
=>
=>---
=>Acee
___

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Wed, 5 Mar 2003 06:21:06 -0800

>points that have not been discussed on the list before.

Thanks Rohit.  I've update the draft with including Kireeti and Alex's
comments.  I hope this help we reach to rough consensus.
--
Kunihiro Ishiguro

---

From: kamatchi soundaram <[email-masked]>
Date: Wed, 5 Mar 2003 11:00:26 -0800

Hello all!,

  I presently working on OSPF un-numbered point to point support. I need
some clarification in implementing this support..

Well! to support this un-numbered point to point, the IP need to support
this feature. If some body put some light on this it will be great! Yes!
even if get some general view about how the IP need to support the
un-numbered point to point of OSPF??

 Is there any standard available for this??

Well! what i know is:
* in case of un-numbered point to point, the one of valid IP address of
other interface will be assigned to this un-numbered p2p. So, that whenever
OSPF sends the packet, it will use this IP address as source address in the
IP header. But how exactly it is implemeted?? Especially in linux kind of
IP. (and stack).

Thanks,
GKS.
NEC america,
CA.

---

From: "Farshad (Sean) Tavallaei" <[email-masked]>
Date: Wed, 5 Mar 2003 18:51:27 -0800

GKS,

RFC 1812 section 2.2.7 is a good start. I think I have seen this done with
Linux using virtual or logical IP addresses or interfaces, or even sometimes
loopback addresses for the unnumbered IP address.

I know that may not be much, but it is a start.

Good luck,

Farshad

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of kamatchi
soundaram
Sent: Wednesday, March 05, 2003 11:00 AM
To: [email-masked]
Subject: Un-numbered point to point. doubt

Hello all!,

Well! what i know is:

Thanks,
GKS.
NEC america,
CA.

---

From: "Farshad (Sean) Tavallaei" <[email-masked]>
Date: Wed, 5 Mar 2003 19:27:39 -0800

GKS,

Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual
links are like the unnumbered links for OSPF. From what I understand, when
sending an OSPF packet through a virtual link, you need to know the
destination IP address, which is supposed to be one of the interface IP
addresses of the remote ABR. If the remote ABR is connected through
unnumbered links only, you may not know any of its IP addresses. You may try
to use looking for a /32 in the router-LSA and using it as the dst if no
interface addresses are available, however, there may be situations where
this is just not possible (i.e., no loopback addresses are announced).

draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers.

Hope that helps,

Farshad

-----Original Message-----
From: Farshad (Sean) Tavallaei [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 6:51 PM
To: Mailing List
Subject: RE: Un-numbered point to point. doubt

GKS,

Good luck,

Farshad

-----Original Message-----

Hello all!,

Well! what i know is:

Thanks,
GKS.
NEC america,
CA.

---

From: klara moser <[email-masked]>
Date: Thu, 6 Mar 2003 09:50:14 -0500

Hi GKS,

Actually,  on  a un-numbered point-to-point interface OSPF will send all its
packets to the well defined All OSPF Routers "broadcast" address. In this case
you do not need a uniquely defined IP address for the remote peer. The only
requirement is that the layer two supports  the OSPF "broadcast" address.

Greetings
Klara

"Farshad (Sean) Tavallaei" wrote:

> links are like the unnumbered links for OSPF.

Except for the virtual link you need the peer address, for unnumbered
point-to-point interface you don't.

> From what I understand, when

---

From: Acee Lindem <[email-masked]>
Date: Thu, 6 Mar 2003 10:55:19 -0500

Klara,

Just one clarification  - AllSPFRouters (224.0.0.5) is
a local-wire multicast address. I know this is what you meant but
wanted to avoid confusion.

--
Acee

---

From: klara moser <[email-masked]>
Date: Thu, 6 Mar 2003 12:16:05 -0500

Thanks Acee,

It is a broadcast address from OSPF protocol point of view, this is why I called it
"broadcast"  :)

Klara

Acee Lindem wrote:

> ? Hi GKS,
> ?
> ? Actually,  on  a un-numbered point-to-point interface OSPF will send all its
> ? packets to the well defined All OSPF Routers "broadcast" address. In this case
> ? you do not need a uniquely defined IP address for the remote peer. The only
> ? requirement is that the layer two supports  the OSPF "broadcast" address.
> ?
> ? Greetings
> ? Klara
> ?
> ? "Farshad (Sean) Tavallaei" wrote:
> ?
> ?
> ??GKS,
> ??
> ??Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual
> ??links are like the unnumbered links for OSPF.
> ?
> ?
> ? Except for the virtual link you need the peer address, for unnumbered
> ? point-to-point interface you don't.
> ?
> ?
> ??From what I understand, when
> ??sending an OSPF packet through a virtual link, you need to know the
> ??destination IP address, which is supposed to be one of the interface IP
> ??addresses of the remote ABR. If the remote ABR is connected through
> ??unnumbered links only, you may not know any of its IP addresses. You may try
> ??to use looking for a /32 in the router-LSA and using it as the dst if no
> ??interface addresses are available, however, there may be situations where
> ??this is just not possible (i.e., no loopback addresses are announced).
> ??
> ??draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers.
> ??
> ??Hope that helps,
> ??
> ??Farshad
> ??
> ??-----Original Message-----
> ??From: Farshad (Sean) Tavallaei [mailto:[email-masked]]
> ??Sent: Wednesday, March 05, 2003 6:51 PM
> ??To: Mailing List
> ??Subject: RE: Un-numbered point to point. doubt
> ??
> ??GKS,
> ??
> ??RFC 1812 section 2.2.7 is a good start. I think I have seen this done with
> ??Linux using virtual or logical IP addresses or interfaces, or even sometimes
> ??loopback addresses for the unnumbered IP address.
> ??
> ??I know that may not be much, but it is a start.
> ??
> ??Good luck,
> ??
> ??Farshad
> ??
> ??-----Original Message-----
> ??From: Mailing List [mailto:[email-masked]]On Behalf Of kamatchi
> ??soundaram
> ??Sent: Wednesday, March 05, 2003 11:00 AM
> ??To: [email-masked]
> ??Subject: Un-numbered point to point. doubt
> ??
> ??Hello all!,
> ??
> ??  I presently working on OSPF un-numbered point to point support. I need
> ??some clarification in implementing this support..
> ??
> ??Well! to support this un-numbered point to point, the IP need to support
> ??this feature. If some body put some light on this it will be great! Yes!
> ??even if get some general view about how the IP need to support the
> ??un-numbered point to point of OSPF??
> ??
> ?? Is there any standard available for this??
> ??
> ??Well! what i know is:
> ??* in case of un-numbered point to point, the one of valid IP address of
> ??other interface will be assigned to this un-numbered p2p. So, that whenever
> ??OSPF sends the packet, it will use this IP address as source address in the
> ??IP header. But how exactly it is implemeted?? Especially in linux kind of
> ??IP. (and stack).
> ??
> ??Thanks,
> ??GKS.
> ??NEC america,
> ??CA.
> ?
> ?
>
> --
> Acee

---

From: kamatchi soundaram <[email-masked]>
Date: Thu, 6 Mar 2003 11:29:30 -0800

Hi,

 Thanks to all of u for ur valuable inputs. Now, i need some specific
clarification..

Lets assume the following is the topoly:
                    R1                     R2
                 ____                   ___
        O----| ___|------------|___|------O
            E1          I1            I2          E2
The topology detail:
1) R1 and R2 are two routers.
2) E1 is ethernet and I1 is un-numbered p2p interface of R1.
3) Similarly E2 is ethernet and I2 is un-numbered p2p interface of R2.
4) Assume E1 is 192.168.12.1 (mask is 255.255.255.0)
5) Assume E2 is 192.168.13.1 (mask is 255.255.255.0)
6) Now as per RFC 1812 (un-numbered p2p support at IP), the interface I1 of
R1 will borrow the IP address of E1 (192.168.12.1) and similarly I2 of R2
borrow the IP address of E2 (192.168.13.1) to specify the source address in
the IP header.
7) Lets assume as per my stack implementation, OSPF uses RAW socket with IP
header inclusion option, for the OSPF packet sending out. In this case, IP
forward/trasmit will receive OSPF packet (Lets say Hello) and IP header with
source as 192.168.12.1 and destination as Multicast address 224.0.0.5.
Case 1:
8) IP will look into the route table to send the packet, obviously it could
not find anything match for this detination, then either it may discard or
just forward the packet to defualt destination (or gateway). In our case it
is more probably the Lan interface. So in this case there is no chance of
OSPF packet to be sent over the Un-numbered point to point interface.

Case 2: If the above problem is because of using RAW socket, and will it be
solved, if OSPF explicity specifies the interface Name/index through which
the OSPF packet need to delivered, then IP will deliver it in the right
interface??

Clarification 2: My other question is: do i need to specify the neighbor
(other end of the interface) IP address, when i configure the Numbered point
to point for OSPF??

Thanks in advance,
GKS
NEC America,
CA USA.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Mar 2003 10:28:44 -0800

Hi Rohit,

> we picked one of the proposals as the WG document.

Before we do that, let me try to summarize what the _real_ issue is.
The read that I got at the last IETF is that OSPFv2 and OSPFv3 are
*different* protocols; that one is focussed on IPv4 and the other
on IPv6.

So, the real question is, do we want to go down this path: create a
major split, and declare v2 and v3 are different protocols.  IMO,
they are very closely related, and building on that closeness rather
than emphasizing the differences is a better path.

So, for example, carrying IPv4 prefixes in OSPFv3 the same way
that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3
as is, etc. seems a cleaner path.  On the other hand, defining new
formats for TE in v3 emphasizes the difference.

I can't speak for all the authors of OSPFv3, but there was a mail by
Dennis Ferguson that seemed to indicate that he would like to see v3
include v2, not as different protocols.  I could be wrong -- but it
would be nice to at least get the opinions of the authors before we
declare a major fork in the road.

Kireeti.

---

From: Rohit Dube <[email-masked]>
Date: Wed, 12 Mar 2003 14:11:41 -0500

Hi Kireeti,

Some comments inline [..]

On Wed, 12 Mar 2003 10:28:44 -0800 Kireeti Kompella writes:
=>Hi Rohit,
=>
=>On Tue, 4 Mar 2003, Rohit Dube wrote:
=>
=>> This issue has been around for a while and it is time that
=>> we picked one of the proposals as the WG document.
=>
=>Before we do that, let me try to summarize what the _real_ issue is.
=>The read that I got at the last IETF is that OSPFv2 and OSPFv3 are
=>*different* protocols; that one is focussed on IPv4 and the other
=>on IPv6.

Yes - one of the main arguments put out in previous discussions is
in fact that OSPFv2 and OSPFv3 are different protocols. I just wanted
to point out that "OSPFv2 is for ipv4 and OSPFv3 is for ipv6" is not
the only significant point of difference. The too protocols differ
in other areas as well : for example generalization of flooding scope
which we have discussed previously on the list.

Certainly the way RFC2740 is written, it deals primarily with ipv6.
And as such OSPFv3 is not adequately specified for ipv4.

=>So, the real question is, do we want to go down this path: create a
=>major split, and declare v2 and v3 are different protocols.  IMO,
=>they are very closely related, and building on that closeness rather
=>than emphasizing the differences is a better path.

IMO this would also mean that 2740 would have to be revisited to
clarify/specify support for ipv4.

=>
=>So, for example, carrying IPv4 prefixes in OSPFv3 the same way
=>that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3
=>as is, etc. seems a cleaner path.  On the other hand, defining new
=>formats for TE in v3 emphasizes the difference.
=>
=>I can't speak for all the authors of OSPFv3, but there was a mail by
=>Dennis Ferguson that seemed to indicate that he would like to see v3
=>include v2, not as different protocols.  I could be wrong -- but it
=>would be nice to at least get the opinions of the authors before we
=>declare a major fork in the road.

Yes I remember this. People can revisit this discussion at the OSPF
archives circa october 2002. During this discussion it was also mentioned
that one of the OSPFv3 authors preferred to run OSPFv3 separately from
OSPFv2 wherever both ipv4 and ipv6 were needed.

Certainly opinions from the co-authors as well as others actively
developing OSPFv3 are very welcome.

=>
=>Kireeti.
___

Best,
--rohit.

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 12 Mar 2003 11:51:33 -0800

Also as an implementor, I think it woold be a major pain
redoing the way IPv4 prefixes are carried in OSPFv3 if
the design is far removed from the existing OSPFv2.

It has taken several years to refine the existing OSPFv2
implementation and iron out all the problems. Redoing the
design will have significant impact on the code stability.

In one implementation, OSPFv3 and OSPFv2 share more than
80 percent of the code. The less than 20 % comes from the
differences between the 2 protocols, which are mainly :

1) Differences in the LSA formats.
2) OSPFv3 runs on a link in a subnet independent manner
while OSPFv2 is subnet dependent. Which also impacts
the nexthop computation.

Doing a redesign of how IPv4 prefixes are carried in
OSPFv3 will require adding some significant amount of
code for translating LSAs from OSPFv2 format to OSPFv3
format.

The only benefit I see of doing away with OSPFv2 and
carrying IPv4 prefixes in OSPFv3 is reduction in
the amount of config a network administrator will have
to do, if he wants to run OSPF for both IPv4 and IPv6.
Other than that I am unaware of any benefits.
I would argue that there are other mechanisms to achieve
that without impacting the protocol itself. I would
also argue that there isn't much difference whether
you run a single protocol to carry both families,
or two different protocols. There difference in the
protocol traffic and the impact on the control plane
resources (e.g. CPU, memory) will be insignificant.

Quaizar

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 12 Mar 2003 12:07:09 -0800

Rohit,

 > which we have discussed previously on the list.

The generalization cleaned up what was a hole in rfc2328. As an
implementor it didn't require a major redesign or significant
code change when adding OSPFv3 support. Compared to 250 odd
pages of OSPFv2, this was a minor change. The way OSPFv3
spec is written, i.e. just describing what is different from
OSPFv2 should be a hint.

 > OSPFv2 wherever both ipv4 and ipv6 were needed.

That is my opinion too.

Quaizar

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Mar 2003 16:40:02 -0500

Glad to see we are getting some good discussion on this issue.

Hi Quaizar - See inline below.

> spec is written, i.e. just describing what is different from

In my opinion, it is an even smaller change to remove the extra
level of hierarchy for applications using OSPFv2 opaque LSAs. Why
have the extra type when we can simply assign a LSA type for
TE LSAs, grace LSAs or foo LSAs? It seems much like a much more
natural classification to me. It is much more likely that I'm going
to want to process all the LSAs for a given application than
all my opaque LSAs.

I also feel that whether or not OSPFv3 will eventually be used
for carrying IPv4 prefixes is a completely independent issue
(othrogonal in IETF-speak ;^).

--
Acee

---

From: Erblichs <[email-masked]>
Date: Sun, 16 Mar 2003 17:07:28 -0800

(1) 1st question...
        2.1 processing OSPF v2 Opaque LSAs.
        (OSPFv2 Opaque LSAs in OSPFv3: draft)

        "An OSPF v3 ... as defined in [OSPFv3]."
        Why? Why don't we handle it in the context
        that the LSA was originated? In OSPFv2. Isn't
        this logic then specific to who recv's the
        LSA?

                Specificly what our our tradeoffs
        if we do OSPFv2 vs v3?

        (2) 2nd question...

        Do we ever want to convert the LSA from OSPFv2
        to be in the proper format as originated by a
        OSPFv3 router? Especially if we are a DR and
        about to flood it to our v3 adjs. Why would
        you want to still send it out as a V2 LSA?

        (3) When would we convert it?

        (4) When wouldn't we convert it?

        (5) When would you flood both types from a v3?
        See the below senario with v2 and v3 being equal.
        Wouldn't this duplicate each recieved LSA by each
        router? Router v3 b recvs LSA from router a (v2),
        duplicates it an sends it to v2 and v3 routers.The
        next v3 router sees the v2 LSA and then creates
        a v3 LSA and forwards that one. Then the v3 version
        then arrives and gets forward. Help....Each time it
        is recieved it gets duplicated. ouch..

        (6) And I assume that the LSAs are originated in v2.
        What happens if we want to originate the v2 from a
        v3 router. Is this allowed? I would think that this
        would then make sense in the section with the #1 below.

        ----------

         Now, I like to step back and look at the
         big picture to see why we want to do this and
        since we are involved with a set of other routing
        protcols, do they have a set way of operation?

        1) What does it really mean if we have an area
        full of OSPFv2 routers and 1 OSPFv3 router? Should
        their be 2-way communciation (sending and
        recieving v2 LSAs from a v3 router)?

        2) Reverse number 1.. Same questions..

        3) What happens if we have equal number of
        OSPFv2/IPv4 and OSPFv3/IPv6, then what is wrong
        with a ships in the night approach?

        4) Do we expect IPv4 pings to be understood with
        IPv6 pings? (aka icmp echo request and reply).

        Should the OSPF versions behave the same?

        And lastly if their was 2-way communication, then
        why not form adjs between the different versions?
        Or at least 1-way nbrs?

        Why not architect the allowance of hellos formed in
        a OSPFv3 be sent to a a OSPFv2 router?? Wouldn't
        this follow the "how OSPF version 2 opaque LSAs can
        be caried in OSPF version 3". Where do you stop?

        Should an interface to a router have socket
        capabilites that now specify whether it is
        IPv4 or IPv6? Thus, if it came on the IPv4
        interface, then it is a OSPFv2 packet, else
        it is a IPv6.

        Sorry, this subject just raises a ton of questions..

        Mitchell Erblich
        Sr. Software Engineer
        ===========================================

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sun, 16 Mar 2003 20:42:41 -0800

>to want to process all the LSAs for a given application than

Agreed.

>(othrogonal in IETF-speak ;^).

Yes.  It is independent issue.  But when we support it, we will define
new LS type.  If we carry IPv4 prefix in OSPFv3 with OSPFv2 Opaque LSA
format....that will be nightmare...
--
Kunihiro Ishiguro

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 17 Mar 2003 13:37:51 -0800

> format....that will be nightmare...

It was never the idea to carry IPv4 prefixes with the v2 Opaque LSA
format.

Let me summarize the issues:
1) do we want to draw a line in the sand and state that OSPFv3 is a
   *different* protocol from OSPFv2?  The alternative viewpoint is
   as far as specs go, v3 cleans up some aspects of v2 that weren't
   done optimally; as far as code goes, v3 implementations can share
   a lot of code with v2.
2) if the answer to the above is that v3 is a refinement of v2, then
   the question is, how much can we borrow from v2 (such as carrying
   IPv4 prefixes and Opaque LSAs in v3 pretty much the same way that
   they are carried in v2)?

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Mar 2003 02:49:09 -0500

>    done optimally; as far as code goes, v3 implementations can share

I'd go with the alternate viewpoint. One of the main motivations for
the OSPFv2 opaque LSA was to solve the problem of how to get LSAs flooded
w/o every router in the OSPF routing domain understanding all the
opaque LSAs types. In OSPFv3, flooding of unknown LSA types is handled
explicitly - this obviates the requirement for opaque LSAs.

>    IPv4 prefixes and Opaque LSAs in v3 pretty much the same way that

Using a new LSA type vis-a-vis a multi-level identifier
<opaque type, embedded LSID type> for each unique class
of LSA is one of the things that is cleaned up in OSPFv3.

Acee