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

[Peter Psenak <[e-mail]>]

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


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


>     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 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>