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

["Peng He" <peng.he.2000@gmail.com>]

Hello Mach,

Thanks a lot for your reply, all clear now.

Regards,
Peng

On 10/10/07, Mach Chen <mach@huawei.com> wrote:
> 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
>
>
>