Subject: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

From: Shraddha Hegde <[email-masked]>
Date: Wed, 21 Oct 2015 05:20:43 +0000

Hi All,

draft-ppsenak-ospf-te-link-attr-reuse-00 proposes moving and/or copying TLVs from the TE Opaque LSA to the Extended Link Opaque LSA. The draft lists the problems that the draft is trying to solve.  I have reproduced that list of problems below, with each problem followed by what I believe to be a better and simpler solution.

   1.  Whenever the link is advertised in a TE Opaque LSA, the link
       becomes a part of the TE topology, which may not match IP routed
       topology.  By making the link part of the TE topology, remote
       nodes may mistakenly believe that the link is available for MPLS
       TE or GMPLS, when, in fact, MPLS is not enabled on the link.

To address this issue, we simply need to define a new sub-TLV in the TE Link LSA  to say whether MPLS/GMPLS/RSVP is enabled on the link instead of moving the TLVs around into different LSAs.

   2.  The TE Opaque LSA carries link attributes that are not used or
       required by MPLS TE or GMPLS.  There is no mechanism in TE Opaque
       LSA to indicate which of the link attributes should be passed to
       MPLS TE application and which should be used by OSPFv2 and other
       applications.

OSPF database is a container and OSPF can use any of the LSAS for its own use including the TE LSAs.  As far as the TE database goes, it contains data from TE LSAs as well as non-TE LSAs (Network LSA) today so the reasoning described here doesn't make sense.

   3.  Link attributes used for non-TE purposes is partitioned across
       multiple LSAs - the TE Opaque LSA and the Extended Link Opaque
       LSA.  This partitioning will require implementations to lookup
       multiple LSAs to extract link attributes for a single link,
       bringing needless complexity to the OSPFv2 implementations.

There will be nodes in the network which will run older software which send these attributes via TE LSAs so the problem of looking into the TE LSAs for TE related information doesn't get solved with this draft.  Rather it makes it more complicated. With this draft, the multiple LSA lookup will only increase.  An implementation will first have to find if Extended link LSA contains the required info,  if not it will need to look up the info in TE.LSA.

Looking up multiple LSAs for information is an implementation issue and I am sure there will be implementations that will handle this  gracefully so that it doesn't cause
delays in critical paths. It doesn't seem reasonable to come up with protocol extensions to solve implementation issues.

Rgds
Shraddha

---

From: Peter Psenak <[email-masked]>
Date: Wed, 21 Oct 2015 10:53:15 +0200

Shraddha,

On 10/21/15 07:20 , Shraddha Hegde wrote:
> Hi All,
> draft-ppsenak-ospf-te-link-attr-reuse-00 proposes moving and/or copying
> TLVs from the TE Opaque LSA to the Extended Link Opaque LSA. The draft
> lists the problems that the draft is trying to solve.  I have reproduced
> that list of problems below, with each problem followed by what I
> believe to be a better and simpler solution.
> To address this issue, we simply need to define a new sub-TLV in the TE
> Link LSAto say whether MPLS/GMPLS/RSVP is enabled on the link instead of
> moving the TLVs around into different LSAs.

let me disagree.

RFC3630 defined TE Opaque LSAs as a  "way of describing the traffic 
engineering topology". What you are proposing is to define a TLV that 
would do exactly opposite and remove link from traffic engineering 
topology. That is a bad idea IMHO.

We have defined Extended Link LSA to advertise link attributes, which is 
independent of the traffic engineering. Using Extended Link LSA to 
advertise link attributes that are NOT related to TE is much cleaner way 
of doing things.

Also we are not moving any of the existing TE/GMPLS/RSVP TLVs anywhere, 
they will still use the TE Opaque LSA.

> OSPF database is a container and OSPF can use any of the LSAS for its
> own use including the TE LSAs.As far as the TE database goes, it
> contains data from TE LSAs as well as non-TE LSAs (Network LSA) today so
> thereasoning described here doesn’t make sense.

Network LSA does not carry any link attributes.

The point is that if you start to use TE Opaque LSA for advertising 
attributes that are not to be used by TE they will be sent to TE as 
well, which is not what we want.

> There will be nodes in the network which will run older software which
> send these attributes via TE LSAs so the problem of looking into the TE
> LSAs for TE relatedinformation doesn’t get solved with this draft.

We are not proposing to modify what we do with TE Opaque LSA in any way.

What we propose is that if some link attributes are used outside of TE, 
advertise them in Extended Link LSA. There is no issue with older 
software at all.

> Rather it makes it more complicated. With this draft, the multiple LSA
> lookup will only increase.An implementation will first have to find if
> Extended link LSA contains the required info, if not it will need to
> lookup the info in TE.LSA.

no. TE will only look at TE Opaque LSA as before.

Extended link LSA will be used internally by OSPF for things like FRR, etc.

> Looking up multiple LSAs for information is an implementation issue and
> I am sure there will be implementations that will handle this
> gracefully so that it doesn’t cause
> delays in critical paths. It doesn’t seem reasonable to come up with
> protocol extensions to solve implementation issues.

we are not trying to solve implementation problem. We are trying to not 
break the existing TE functionality by reusing TE Opaque LSA for 
something it has not been defined for.

thanks,
Peter

> Rgds
> Shraddha
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>