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

[Acee Lindem <[e-mail]>]

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-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":)

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,
>> Acee
>>
>
>
>
> Best regards,			
> Mach Chen
>