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

From: Mach Chen <[email-masked]>
Date: Wed, 26 Sep 2007 18:10:52 +0800

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.

>
>
>>
>>
>> 2.       Section 2.
>>
>> “The format of the TLVs within the body of a router information LSA  
>> is the same as the format used by the Traffic Engineering  
>> Extensions to OSPF [TE].”
>>
>>
>>
>> What’s “a router information LSA”?  Or should it be “an Intra-Area- 
>> TE LSA” ?
>
>Yes. Good catch. I'll fix this.

Thanks.

>Thanks,
>Acee

Best regards,			
Mach Chen

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Sep 2007 10:14:36 -0400

Hi Mach,

On Sep 26, 2007, at 6:10 AM, Mach Chen wrote:

> 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?
>
> 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? I know at the OSPF meeting there were a number of  
people who questioned whether or not it was necessary.

Thanks,
Acee

---

From: "Alan Davey" <[email-masked]>
Date: Thu, 27 Sep 2007 10:48:59 +0100

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.

*	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. 

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.

	-  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.

*	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.

Regards

Alan Davey

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   +44 20 8366 1177
Fax:   +44 20 8363 1039
Email: [email-masked]
Web:   http://www.dataconnection.com

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]] 
> Sent: 26 September 2007 15:15
> To: Mach Chen
> Cc: OSPF List; Vishwas Manral; Alan Davey; CCAMP List
> Subject: Re: [OSPF] Fwd: Posting of 
> draft-ietf-ospf-ospfv3-traffic-09.txt
> 
> Hi Mach,
> 
> >>> something like "OSPFv3 TE LSA"?
> > has to be defined for advertising inter-AS TE information 
> in support 
> > of OSPFv3 TE, am I right?
> >
> > 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.
> 
> extension-01.txt? I know at the OSPF meeting there were a 
> number of people who questioned whether or not it was necessary.
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> >
> >>
> >>
> >>>
> >>>
> >>> 2.       Section 2.
> >>>
> >>> "The format of the TLVs within the body of a router 
> information LSA 
> Extensions 
> >>> to OSPF [TE]."
> >>> What's "a router information LSA"?  Or should it be "an 
> Intra-Area- 
> >>> TE LSA" ?
> >>