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