Re: OSPFv2 Opaque LSAs in OSPFv3

["Naidu, Venkata" <[e-mail]>]

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.