Re: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt

[Mach Chen <mach@huawei.com>]

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-TE
>>>> LSA, 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-TE
>>>> LSA, 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 LSA
>>> types 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 discrepancy
>>> exposes the choice of a new link type for inter-AS connectivity as a
>>> bit 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":)

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

>
>Thanks,
>Acee
>



Best regards,			
Mach Chen