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

[Mach Chen <mach@huawei.com>]

Hi Peng,
  
On 2007-10-10, at 11:50:55 Peng He wrote:

>Hello Mach,
>
>> Sorry for the late response(Just return from long national holidays)
>>
>
>Understood :-)
>>
>>
>> On 2007-10-03, at 10:33:31 Peng He wrote:
>>
>> >Hello Mach,
>> >
>> >Just be curious about the following:
>> >>>3. Add the missing part about that the local ASBR SHOULD do a
>> >"proxy" advertisement for the backward of an inter-AS TE link;
>> >
>> >What do you mean by "the backward of an inter-AS TE link"? Does that
>> >mean that local ASBR would advertise TE info about the incoming
>> >inter-AS link(s)? Thanks.
>>
>> Yes, due to there is no OSPF adjacency running on the inter-AS link, and some >implements(CSPF) will do a two-way check before using the link for path computation, so >the local ASBR should advertise the TE info of the inter-AS TE link from the view of the >remote ASBR.
>
>One question:  so the local ASBRs "advertise the TE info of the
>inter-AS TE link(s) from the view of the remote ASBR." is only for the
>purpose of "...do a two-way check before using the link for path
>computation" and the "two-way check" is only for making sure the
>link(s) is available.

Yes, and to make sure that the remote LSR is available. 

>
>Will the TE info of incoming inter-AS link(s) be considered into path
>computation process (by CSPF) like what it does to outgoing inter-AS
>TE link(s)? 

As I know, in order to make sure the validity of a path, most of the existing implements do perform such two-way check. 

>Or your I-D just provides this "potential" capability,
>weather to use it depends on the detailed implementations?
>
Theoretically, you may say that, but as I said above, most of implement will use it.


>
>Regards,
>Peng


Best regards,			
Mach Chen