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.
