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

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

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

Hi Peng,

Best regards,			
Mach Chen

---

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

Hi Alan,

Thanks for your useful comments!

On 2007-09-27, at 17:48:59 Alan Davey wrote:

>Guys
>
>Apologies for the late response.  
>
>I basically agree with Acee.
>
>*	It makes sense to define a new OSPFv3-TE LSA type to carry the
>AS connectivity information.  I think that this would probably provide a
>better and more back compatible way to identify the new advertisements
>than defining a new link type value.

Agree, a new LSA type is a better option for OSPFv3 inter-AS TE.

>
>*	It also makes sense to use the same approach in OSPFv2 and
>OSPFv3 and so a new OSPFv2 opaque type may be the way to go. 
>

We are considering whether define a new OSPFv2 opaque type.

>My other comments on the draft, from an OSPFv3 TE perspective, are as
>follows.
>
>*	On the subject of identifying the other end of the inter-AS
>link.
>
>	-  The Link ID sub-TLV is not suitable as it SHOULD be ignored
>on receipt by an OSPFv3 TE implementation.  
>
>	-  The Neighbor ID sub-TLV MUST be used instead.  This sub-TLV
>contains the neighbor's interface ID and the neighbor's 32-bit Router ID
>(note that this is NOT the TE Router ID).
>
>	-  Use of the Neighbor ID sub-TLV requires configuration at the
>ASBR of the remote ASBR's interface ID and the 32-bit Router ID.
>

Yes, for OSPFv3 inter-AS TE, this will be performed as the current OSPFv3 TE does.

>	-  You may want to advertise a global-scope IPv6 address for the
>router at the other end of an inter-AS link in a Remote Interface IPv6
>Address Sub-TLV.  This would also need to be configured.
>

>*	As Acee pointed out, there is currently no OSPFv3 TE equivalent
>to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding
>AS scope TE information.

So, allocating a new separate LSA could make it easyly for the inter-AS TE information having area or AS flooding scope.
 
>
>*	The wording needs to be changed for OSPFv3 TE when describing
>the contents of a "proxy" advertisement for the backward direction of an
>inter-AD TE link.
>

OK.

>Regards
>Alan Davey

Best regards,			
Mach Chen

a02-in.huawei.com> for
	[email-masked]; Wed, 10 Oct 2007 10:37:24 +0800 (CST)
Date: Wed, 10 Oct 2007 10:37:07 +0800
From: Mach Chen <[email-masked]>
Subject: RE: [OSPF] Fwd: Posting of draft-ietf-ospf-ospfv3-traffic-09.txt
To: Alan Davey <[email-masked]>
Cc: CCAMP List <[email-masked]>, OSPF List <[email-masked]>,
	Vishwas Manral <[email-masked]>

Hi Alan,

Thanks for your useful comments!

On 2007-09-27, at 17:48:59 Alan Davey wrote:

>Guys
>
>Apologies for the late response.  
>
>I basically agree with Acee.
>
>*	It makes sense to define a new OSPFv3-TE LSA type to carry the
>AS connectivity information.  I think that this would probably provide a
>better and more back compatible way to identify the new advertisements
>than defining a new link type value.

Agree, a new LSA type is a better option for OSPFv3 inter-AS TE.

>
>*	It also makes sense to use the same approach in OSPFv2 and
>OSPFv3 and so a new OSPFv2 opaque type may be the way to go. 
>

We are considering whether define a new OSPFv2 opaque type.

>My other comments on the draft, from an OSPFv3 TE perspective, are as
>follows.
>
>*	On the subject of identifying the other end of the inter-AS
>link.
>
>	-  The Link ID sub-TLV is not suitable as it SHOULD be ignored
>on receipt by an OSPFv3 TE implementation.  
>
>	-  The Neighbor ID sub-TLV MUST be used instead.  This sub-TLV
>contains the neighbor's interface ID and the neighbor's 32-bit Router ID
>(note that this is NOT the TE Router ID).
>
>	-  Use of the Neighbor ID sub-TLV requires configuration at the
>ASBR of the remote ASBR's interface ID and the 32-bit Router ID.
>

Yes, for OSPFv3 inter-AS TE, this will be performed as the current OSPFv3 TE does.

>	-  You may want to advertise a global-scope IPv6 address for the
>router at the other end of an inter-AS link in a Remote Interface IPv6
>Address Sub-TLV.  This would also need to be configured.
>

>*	As Acee pointed out, there is currently no OSPFv3 TE equivalent
>to the Type 11 Opaque LSA, that is, there is no defined LSA for flooding
>AS scope TE information.

So, allocating a new separate LSA could make it easyly for the inter-AS TE information having area or AS flooding scope.
 
>
>*	The wording needs to be changed for OSPFv3 TE when describing
>the contents of a "proxy" advertisement for the backward direction of an
>inter-AD TE link.
>

OK.

>Regards
>Alan Davey

Best regards,			
Mach Chen