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.
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.
The draft apparently evolved over time with no requirements
document to guide it.
Perhaps you should read RFC 2702 before making comments.
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?
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.
Large OSPF networks with multiple areas will not
run this protocol.
Crystal ball? I suggest you get a new one.
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.
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"?
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.
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'.
While I respect your right to comment (that is after all the point
of an IETF Last Call), I would really suggest you do your homework
before you comment.
In summary, I have read and responded to the comments above; in my
opinion, they do not warrant any changes to the document. However,
if any one else feels otherwise, please do not hesitate to let me
know, and I will reconsider my decision.
Kireeti.