Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 16:14:35 -0700

Hi Alex,

>  If I understand Kireeti's idea correctly, the suggestion is to "map"
>  the Opaque LSA mechanism in v2 to the generic scoped flooding
>  mechanism in v3; and it is primarily driven by the desire to get TE
>  extensions to v3 faster. Below is my view on this.

Pretty good summary.  Small change: "faster, with maximal code reuse"

>  Opaques LSAs used
>  in v2 may affect protocol mechanisms that are specific to v2 and are
>  not applicable in v3, or they may contain information that makes
>  sense in the IPv4 world only. Just saying that we now have this stuff
>  in v3 is not enough, one has to go and specify how this info is
>  interpreted there.

There are (at least) four ways to get a spec from v2 into v3 (where
a "spec" defines a specific Opaque LSA type, such as TE or Grace LSA):
a) redo the spec and the code, clean it up, tailor it to v3 and IPv6;
b) map the spec and code wholesale into v3;
c) map the spec on a section-by-section (or TLV-by-TLV) basis from
   v2 to v3;
d) map the entire notion of v2 Opaque LSAs into v3.

(a) would be wonderful.  Unfortunately, things aren't always as nice
    as they could be; code, deadlines, migration, etc. get in the way.
    This is not to say that this approach is wrong -- in fact, it is
    the only correct approach.  Fortunately, there is no conflict:
    one can do (a) in parallel with (b) (c) or (d).

(b) is the approach, as near as I understand it, that Vishwas was
    suggesting.  Close in spirit with (d) below.

(c) is, if I understand you correctly, the approach you are suggesting.
    Would be a strong requirement if there were lots of pre-existing
    Opaque LSAs; however, there are only a couple or so.  Also, see below.

(d) is the approach that I was foolish enough to propose.  Quick and
    dirty, easy, maximizes code reuse.

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.

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).

Kireeti.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 8 Oct 2002 18:04:03 -0700

Thanks for your response, Kireeti.
See below, please.

> Pretty good summary.  Small change: "faster, with maximal code reuse"

Accepted :)

> (c) is, if I understand you correctly, the approach you are suggesting.

Not necessarily on a section-by-section/TLV-by-TLV basis as you
mentioned above. Instead, if, for example, we need to get the TE
extensions into v3, we would come up with a draft-ospf-ospfv3-katz-yueng
and specify the LS Type for TE LSAs, refer to katz-yueng for things
like body formatting, enumerate TLVs (by reference, not value) that
are IP-version independent and are valid for v3, and then go and
address the IPv6 specific details.

This way we make sure that we have good code reuse, and things are
properly specified at the same time. If things are so similar that
nothing needs to be changed (e.g., I finally write an Apr 1 draft on
DNS over BGP, together with a BCP on redistributing this DNS info into
IGPs using v2 Opaque LSAs and v3 LSA foo), the document is really
small and says "here's the LSA function code, the rest is as there".
I'm afraid, however, that this is not the common case and there will
be IPv6/OSPFv3 specific details...

>     dirty, easy, maximizes code reuse.

It could be a brilliant hack, I have to give you that.

> straightforward manner to v3. So, we don't have a huge "legacy" problem.

But they don't map directly from v2 to v3 and from IPv4 to IPv6,
however. We'd still need to address issues like those Ishi brought up.

Besides, while for the GMPLS world OSPFv2 and OSPFv3 might seem like
just two very similar transport mechanisms for TE info, it is very
different for the protocols themselves. It is perfectly possible, for
example, to have an extension to OSPFv2 that uses Opaque LSAs, but
that makes not sense at all in OSPFv3.

> anyway, and minimizes the need for (c).

Given that:

  a) we will need to go and think carefully about possible
     implications of moving a specific feature to the IPv6/OSPFv3
     environment every time we do that

  b) those implications will be specific to each feature
     being "migrated"

  c) those implications will need to be properly documented

 and that

  d) assignment of the LSA function is a non-issue

I think that creating the "automatic/implicit specification" back door
between the protocols is not warranted. In fact, I am really worried
that this implicitness will result in inadequate specification.

Thanks.
Alex

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Tue, 8 Oct 2002 18:27:36 -0700

>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.

>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

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 8 Oct 2002 19:28:26 -0700

> to aware current extensions can't be applicable to IPv6 without change

This TLV is optional and more over the purpose of this TLV is to
identify the neighbor from its interface address. In OSPF V3 this is
done by using the Router-id which is also a 32 bit - hence could fit
in here.

I am actually submitting a draft regarding the use of this TLV in OSPFv3
and it will actually carry the router-id in a new TLV.

I think that the best approach would be to have different TLV that are either
OSPFv2 or OSPFv3 specific regarding ipv4/ipv6. My preference would be
to have those TLVs to have the same suffix for example :
TLV 3 -    ipv4
TLV 1003 - ipv6

Padma

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 20:07:26 -0700

> Kireeti, how do you think about this?

It's not like I'm given much choice by the AD.

Plan B: write a short draft that basically grabs an LS function code
for TE, defines that the LSA body format remains the same and states
that all current TLVs "just work" (since they do).  Also, define *new*
sub-TLVs for local and remote IPv6 addresses.  Finally, state how
Instances are identified.

If you're doing this, I have two requests:
a) Please avoid redefining sub-TLVs 1-16 of the Link TLV;
b) Make the new sub-TLVs applicable to both OSPFv2 and v3.

BTW, diffserv TE and GMPLS are just subcases of TE.  I'd suggest that
        draft-katz-yeung-ospf-traffic-08.txt,
        draft-ietf-tewg-diff-te-proto-01.txt and
        draft-ietf-ccamp-ospf-gmpls-extensions-08.txt
be cited normatively in your draft.

I don't know if a new v6 Router Address TLV is needed: you may want to
research that.

Good luck!
Kireeti.

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Wed, 9 Oct 2002 07:46:00 -0700

>a) Please avoid redefining sub-TLVs 1-16 of the Link TLV;

OK.  I've used 9,10,11 in OSPFv3 TE draft.  I'll change it.

>be cited normatively in your draft.

So far I have below point to make it applicable OSPFv2 extensions to
OSPFv3.

1. IPv4 address

Whe the draft refer IPv4 address, IPv6 address support should be
there.

2. IPv6 address

When draft flood IP address to no local flooding scope, link-local
address should not be flooded.  It is not valid address outside link
local.

3. Router Address TLV for Router ID

When draft use Router Address TLV for referring Router ID.  That is
realy Router ID in OSPFv3 and the address may not be reachable.

4. Identification key for Network-LSA

Identification key for Network-LSA (there is a case we have to map LSA
to Network-LSA) is not same as in OSPFv2.  In OSPFv3 Neighbor
Interface ID and Neighbor Router ID is needed.
--
Kunihiro Ishiguro

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 9 Oct 2002 10:26:28 -0700

> OK.  I've used 9,10,11 in OSPFv3 TE draft.  I'll change it.

Thanks!

> Whe the draft refer IPv4 address, IPv6 address support should be

My point is that there is no reason in principle that the v2 draft
should not carry IPv6 addresses, or that the v3 draft should not carry
IPv4 addresses.  In fact, if TE is used to set up RSVP LSPs, then it
is worth noting that RSVP/IPv4 can signal tunnels addressed by IPv6.

So, I would prefer that document say explicitly that the new TLVs
for IPv6 addresses can be used in both v2 TE and v3 TE.  If that's
what you've done (I'm still waiting for your draft to post), great!

> address should not be flooded.  It is not valid address outside link

If you mean there's no use flooding link local IPv6 addresses, agreed.

Note that unnumbered support is already there (see the GMPLS draft).

> Interface ID and Neighbor Router ID is needed.

Okay.

Kireeti.