Hi Mach, On Sep 29, 2007, at 1:12 AM, Mach Chen wrote:
Hi Acee , Sorroy for late reply. On 2007-09-26, at 22:14:36 Acee Lindem wrote:Hi Mach, On Sep 26, 2007, at 6:10 AM, Mach Chen wrote:Hi Acee, Pls see inline On 2007-09-25, at 21:05:49 Acee Lindem wrote:Hi Mach, Thanks for reviewing. On Sep 25, 2007, at 4:24 AM, Mach Chen wrote:Hi Acee and other authors, Some questions to ospfv3-traffic 1. In this ospfv3-traffic document, a new LSA, Intra-Area-TELSA, is defined to advertise IPv6 TE information. From name of this new LSA, IMHO, it is limited to be used for Intra-Area TE only. So,if there are some underlying extensions to ospfv3-traffic, e.g.Inter-AS TE, it is a little bit strange to re-use the Intra- Area-TELSA, or it has to define a new LSA. So, can we change its name to something like “OSPFv3 TE LSA”?It would be if we had intended it to carry AS wide information.However, it was not initially intended for this. The initial thought was that we would do a better job for OSPFv3 and define separate LSAtypes for intra-area, inter-area, and AS external TE LSAs. Thoughts on this (copied ccamp as well)?So, the conclusion is that a new LSA(may be called Inter-AS-TE LSA) has to be defined for advertising inter-AS TE information in support of OSPFv3 TE, am I right?I guess, IMHO, this discrepancyexposes the choice of a new link type for inter-AS connectivity as abit of a hack.For OSPFv3 TE(separate LSAs are used) is YES. But as to OSPFv2 TE, IMHO, there should be a new link type to identify an inter-AS link, or we need another new LSA.It seems to me that if we do add the link in your draft, then it should be done the same in OSPFv2 and OSPFv3. Advertising it as a new link type is one way to advertise inter-AS connectivity. However, it isn't necessarily a link. This seems to me to be more of a semantical discrepancy than the name of the LSA. In section 4, I notice that at least for OSPFv2 the draft says the new link may be advertised in either a type 11 opaque LSA or type 10 opaque LSA. Given the maturity of RFC 3630, it almost seems to me that we should allocate a new LSA opaque type for this purpose. What is the status of draft-ietf-ccamp-ospf-interas-te- extension-01.txt?The I-D has been updated recently according to the comments received from Chicago meeting. The main changes inlcude:1. According to Kireeti's comments, make a clear statement "There is no OSPF adjacency running on the inter-AS link";2. Enhance the PCE-based scenario to explain that the AS number property of an inter-AS TE link is needed, and clearly state that the AS number sub-TLV is mandatory;3. Add the missing part about that the local ASBR SHOULD do a "proxy" advertisement for the backward of an inter-AS TE link;4. Enhance the Security section.Currently, IMHO, the I-D can support OSPFv2 properly, due to the diffence between OSPFv2 TE and OSPFv3 TE, some changes are needed in order to encompass OSPFv3, so the status of the I-D is "work in progress":)
Ok - will review the next version.
I know at the OSPF meeting there were a number of people who questioned whether or not it was necessary.I am not sure the necessary you pointed is pointed to the new link type or the Inter-AS TE I-D. Because I did not hear any questions about the necessary of the I-D, so I assume that you poinited is the new link type. As I pointed before, if a new sepatate LSA is used, the new link type may not be needed.
Sounds good, I haven't seen much dissension on the CCAMP list. Thanks, Acee
Thanks, AceeBest regards, Mach Chen