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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
