>So, let's see where we are. There are two Opaque LSA types that I am
>familiar with: TE LSAs and Grace LSAs. Both of these migrate in a very
>straightforward manner to v3. So, we don't have a huge "legacy" problem.

Grace LSAs has IP interface address (Type=3, length=4) which assumes
IPv4. We'll need IPv6 interface address (new TLV). Sorry for saying
this kind of things again and again... But this is a good opportunity
to aware current extensions can't be applicable to IPv6 without change
or adding new TLV type.

>The simple thing to do is to mandate that when new OSPFv2 Opaque LSAs
>are defined, the authors state on a per TLV/section/spec/... basis what
>migrates to v3 and what is v2-only. This is probably a Good Thing to do
>anyway, and minimizes the need for (c).

I agree with it. When we define a new extension to OSPF it is good to
have both OSPFv2 and OSPFv3 at the same time. TLV should be common
both two protocol. We should be careful to avoid implicit assumption
about IP address (it can be IPv4 or IPv6). And we can't assume that
router-id 4 octet value is reachable as real IP address...

                         OSPF new extension X

1. Description of the new extension X

2. TLV definitions which aware IPv4 and IPv6.

Apendix A. Packet format in OSPFv2

Description of Opaque LSA format and Opaque code...

Apendix B. Pakcet format in OSPFv3

Just Define LS type code ;-).

(This is my preference but if we think exporting Opaque LSA is better,
it is doable).

Kireeti, how do you think about this? If you think this is same idea
you are thinking about, I'm going to work on revising existing OSPF
extensions draft such as TE, diffserv, restart, GMPLS to make it sure
it can be applicable to IPv6 network.

--
Kunihiro Ishiguro

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]