<... snip>
Hi,
On Mon, 16 Dec 2002, Pyda Srisuresh wrote:
The draft is a solution to providing TE within an OSPF area.
Yes.
The draft has serious scalability limitations in
extending this to inter-area and mixed networks (with TE and
non-TE nodes). Please see my comments below.
Actually, inter-area TE is a hard problem -- however, the issue is not
how you format the bits or what type of LSA you use, but what
information should be carried, how it should be summarized (if at all
that is a feasible approach), minimizing crankback, etc.
You forgot to mention flooding.
I would not
recommend using this draft as the basis for building further
TE-extensions to inter-area and mixed networks.
Your recommendation is noted. Of course, that is not the issue at
hand -- the issue at hand is a proposal for *intra-area* TE.
You are right. The draft at hand is about intra-area TE.
There are many reasons why I recommend the draft be not
extended to inter-area and mixed networks. There is often
a tendency to assume extensibility or using the existing
draft/RFC as the basis for inter-area and mixed networks
unless stated otherwise. It is also concerning because the
OSPF WG currently has no drafts in its charter to cover
inter-area and mixed networks. Lastly, this intra-area draft
is bound to impose backward compatibility requirements on
any follow-on drafts covering inter-area and mixed networks.
Hence, a statement of applicability and limitations is
warranted in the draft.
The draft apparently evolved over time with no requirements
document to guide it.
Perhaps you should read RFC 2702 before making comments.
Kireeti - I am aware of RFC 2702 and have reviewed it.
The RFC is about requirements and applications of TE over MPLS.
The RFC is *not* about requirements for the IGP collecting
TE metrics within an Autonomous System(AS). I was refering
to the latter.
The vendors and implementors behind the
draft may have been guided by different set of requirements
and motivations, such as having some working code.
Your point being that working code is a Bad Thing?
I am saying that the problem should be well defined,
before you decide on a solution.
Having "some" working code that solves a problem is not the
same as having working code that implements a solution to a
well-defined problem.
Below are my specific comments on the draft.
1. The draft basically describes link TLVs for area-wide
flooding. OSPF is an AS-wide IGP, not just area-wide.
So, I would suggest renaming the draft as "TE extensions
to an OSPFv2 area", instead of the current title,
"TE extensions to OSPFV2".
If you're going to comment on the title, please at least get it right:
it's "Traffic Engineering Extensions to OSPF Version 2".
Your suggested title would be unnecessarily long; anyone who can read
the very short (20 word) abstract will learn that this is for intra-area
TE post haste.
Truth in labeling is important; And, I suggested a label that
is truthful and will fit in a line.
The whole crux of my comments has been on scaling and applicability
limitations.
Large OSPF networks with multiple areas will not
run this protocol.
Crystal ball? I suggest you get a new one.
READ - This protocol is restricted in scope to a single area.
I will leave the crystal ball business to the market.
2. It is confusing to refer an opaque LSA with with a
specific sub-type as "TE LSA". It makes it sound like a
stand-alone OSPF LSA with a distinct LSA type - which
is is not. OSPF LSAs define the flooding scope. TE LSA
does not.
One suggestion would be to refer Opaque LSAs with specific
sub-type 1 as "TE-type Opaque LSA".
This is beyond nitpicking. Note that the Opaque LSA for Graceful
Restart is called the Grace LSA; also that many many other documents
besides this one call the "TE-type Opaque LSA" simply a TE LSA.
What is the RFC that uses the term "Grace LSA" ?
This is not nitpicking. It is just a matter of using the
terminology right, so it doesnot cause semantics confusion.
I pointed out what the confusion is. Hope you understand.
3. The limitations section (section 1.2) should mention the
following limiations with a mixed network containing TE
and non-TE nodes.
1. When a network area is constituted of TE and
native-nodes (supporting IP-only links), the opaque
LSAs will flood all nodes in the area, thereby
disrupting native OSPF nodes.
As As a general rule, a TE network is likely to generate
significantly more control traffic than a native OSPF
network. The excess traffic is almost directly proportional
to the rate at which TE circuits are set up and torn down
within the TE network.
The more frequent and wider the flooding frequency,
the larger the number of retransmissions and Acks.
It is undesirable to flood non-TE nodes with TE TLVs.
Do you know of any "mixed networks"?
I would reframe the question as - Can you assume there wont be
any mixed networks?
You're right, however, that if non-TE-capable nodes are present in the
network, they will have to flood the LSAs carrying TE information as
well. However, this is a natural characteristic of OSPF flooding and
Opaque LSA mechanism not changed by the TE extensions, hence does not
need to be explicitly explained.
Yes. The draft uses Opaque LSA to propogate TE metrics.
Naturally, all the limitations of the opaque LSA will limit
the TE extensions.
2. A link cannot be reserved for TE-only use. All links
must be subjectable to best-effort IP traffic first,
before any of the links are permitted to carry TE traffic.
This is patently false. There are two methods of "reserving" links
for TE-only use, one of which is documented in "LSP Hierarchy with
Generalized MPLS TE", the other being the obvious 'advertise the link
LSA with infinite SPF metric'.
OK, let me try this differently.
In the intra-area TE extensions proposal, all IP networks
(TE and non-TE alike) belong to the same address space and
are advertised on all links, TE and non-TE alike.
When a node does not have non-TE links (or a non-TE link
went down), IP packets are still forwarded using the shortest
path. I am not aware of a way to notify the router to not
forward IP packets on a TE link. As a result, TE link(s) with
infinite cost will be used to forward IP packets. When multiple
TE links exist on the same node to reach an IP network, and all
TE-links are configured with infinite SPF metric, the first TE
link will still be used to repeatedly to forward IP traffic.
Hope this explains.
<... snip>
regards,
suresh