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

From: Mach Chen <[email-masked]>
Date: Wed, 10 Oct 2007 10:37:14 +0800

Hi Peng,

Sorry for the late response(Just return from long national holidays)

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.  

>Regards,
>Peng

Best regards,			
Mach Chen

---

From: "Peng He" <[email-masked]>
Date: Tue, 9 Oct 2007 23:50:55 -0400

Hello Mach,

> Sorry for the late response(Just return from long national holidays)

Understood :-)
> 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.

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)? Or your I-D just provides this "potential" capability,
weather to use it depends on the detailed implementations?

Regards,
Peng