Re: OSPFv2 Opaque LSAs in OSPFv3

[Alex Zinin <[e-mail]>]

Venkata,

  There's no problem in OSPFv3 providing transport-like services to
  non-OSPF "applications", this concept is just already in the
  protocol, we don't have to specify anything extra here.

  My objection is against the idea of mapping/linking/shortcutting all
  Opaque-LSA-based *extensions* to OSPFv3. This idea is based on the
  assumption that migration of those extensions from IPv4 to IPv6 or
  from OSPFv2 to OSPFv3 environment will generally not require any
  additional specification. While this may be true for some specific
  "applications", I don't believe we can safely assume this as a
  general case.

  We are here to make sure independent interoperable implementations
  can be developed, which means that things need to be properly
  specified. My standing in this discussion is to ensure that we do
  not make a mistake that will create the underspecification problem.

  Thank you.

--
Alex

Thursday, October 10, 2002, 10:05:39 AM, Naidu, Venkata wrote:
> Kireeti & Alex,

>   I am late into the field - please excuse and consider
>   my points.

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

>   Kireeti has a very valid point here. Alex's point is independent
>   of what we (MPLS folks) have to do at this point of time.

>   I view MPLS-TE a "service user" of OSPF (v2 or v3) "a service
>   provider" for flooding the information transparently to other
>   side of MPLS-TE layer.

>   If, by chance, OSPFv3 is running in the topology, and If the
>   application (here, for example, still MPLS-TE for IPv4) would
>   like to pass the info (OSPF should not care about what the
>   information is) to the other side, then it should. *Application*
>   (for example MPLS-TE for IPv4) knows what is the info - here it
>   is still IPv4 - for the reasons mentioned  by Kireeti.

>   Alex, let me put it in other way - define a LS Type in OSPF v3
>   and call it "User defined LS Type" and reserve *one* (just one)
>   for OSPF v2 Opaque LSAs. Now with very minimal changes, all the
>   IPv4 applications which used OSPF v2 Opaque LSAs can be flooded
>   even when OSPF v3 is running in the network.

>   Alex's point is valid when MPLS-TE for IPv6 (which is different
>   application when compared to MPLS-TE for IPv4) is used in the
>   network. For this, any way, we need a clear draft which considers
>   IPv6 requirements, etc etc.

>   Alex, there are almost nearly 20 different IPv4 applications
>   using OSPF v2 Opaque LSAs (MPLS-TE is just one of them). So please
>   consider the fact that, all those applications must work if the
>   version of OSPF is changed from v2 to v3 with minimal work.

>   Bottom Line: It is the application who decides whether to write
>   a new draft for IPv6 or not by taking the new requirements for IPv6
>   (if there are any). A service provider (here OSPF) should not ask
>   applications to change their behavior or information when it's own
>   operation/version changes. What it should possible do is, provide
>   a transport mechanism (a SAP) to all those previous applications,
>   so that the information is flooded intact.

>   Please don't think otherwise - kindly interrupt me if I am not
>   in the same page :)

> --
> Venkata.