Subject: Re: OSPFv3: what is the use of prefixes in Link LSA

From: "Goyal, Manoj" <[email-masked]>
Date: Tue, 14 Mar 2006 11:45:54 -0800

That makes sense to keep the link LSA with one optional
Global prefix and omit the rest of the prefixes for p2p. These link
LSAs may also play a role in Traffic-Engineering for OSPFv3 or
other applications.

Thanks,
Manoj
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Tuesday, March 14, 2006 11:37 AM
To: [email-masked]
Subject: Re: OAPFv3: what is the use of prefixes in Link LSA

Hi Paul,

I tend to agree - the advantage is marginal. The only reason I could
see for putting a single global prefix on a P2P link would be for the
Network Management monitoring applications that ping every
interface in the network.

Thanks,
Acee

Paul Wells wrote:

> Hi Acee,
>
> Opinion inline.
>
> Acee Lindem wrote:
>
>> Hi Manoj,
>>
>> Goyal, Manoj wrote:
>>
>>> Hi Acee,
>>> I feel a description could be added to make it clear that:
>>>
>>> - the link LSAs are only required for broadcast and NBMA links.
>>> - for p2p links they are not required (or optional)
>>> - and if a link LSA is generated for a link that is p2p,
>>>  then it should not include any prefixes as they are already
>>>  available in intra-area-prefix LSAs.
>>>
>>> Even for the implementation purpose, during route calculation,
>>> getting the link-local address on a p2p link though its neighbor
>>> is quicker/easier then parsing the link-lsa of the neighbor
>>> to get the link-local address from there.
>>>  
>>>
>> I'd certainly agree here - also you don't really need the next-hop 
>> address on a p2p
>> link. However, I'd hate to render an existing RFC 2740 implementation

>> incompatible
>> without at least a knob. I do not, however, see much value to 
>> including the global
>> prefixes in the link LSA for p2p or p2mp links. Any other opinions
here?
>
>
> There are two separate issues here.  The first one discussed was 
> whether  global prefixes are really needed in the link lsa for p2p 
> links. Offhand I can't think of a case where they are, but I'm not 
> sure I see a big advantage in having a special case to omit them.
>
> The second question was whether link lsas and their link-local address

> are required for p2p links at all.  Here I would argue for retaining 
> the current specification that requires them.
>
> While an implementation may have a link-local address for it's 
> neighbor in the neighbor structure, I think that there is significant 
> architectural value in keeping the link state database self-sufficient

> for computing routes.  For one thing, there may be cases where the 
> lsdb is being used by applications other than routing and the neighbor

> structure may not available.  Also, as you point out, there may be 
> existing implementations based on 2740 that depend on it.  I'm 
> unconvinced that the very minor savings of memory and cpu gained by 
> omitting the link lsas are worth it.
>
> Thanks,
> Paul
>
>>
>> Thanks,
>> Acee
>>
>>> Thanks,
>>> Manoj
>>>
>>> -----Original Message-----
>>> From: Mailing List [mailto:[email-masked]] On Behalf Of
Acee
>>> Lindem
>>> Sent: Thursday, March 09, 2006 4:44 PM
>>> To: [email-masked]
>>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA
>>>
>>> Goyal, Manoj wrote:
>>>
>>>  
>>>
>>>> I think I asked the first question in a wrong way, sure that
>>>> the link LSAs are used by the DR to construct the IAP-LSA for the
>>>> broadcast network.
>>>> But what is the use of the link LSAs having prefixes for
>>>> P2P links as all the prefixes are present in the router's
>>>> IAP LSAs already?? Practically most links are P2P.
>>>>
>>>>
>>>>   
>>>
>>>
>>> Hi Manoj,
>>>
>>> In the RFC 2370 update draft, I added text explicitly stating that 
>>> link LSAs are not
>>> needed for virtual links. I considered saying they MAY be omitted
>>> on p2p links as well but was worried that conceivably an 
>>> implementation could
>>> use link LSAs exclusively for next-hop computation (they are needed 
>>> for next-hop
>>> computation on NBMA links). Are there other opinions on this?
>>>
>>> Thanks,
>>> Acee
>>>
>>>  
>>>
>>>> Manoj
>>>>
>>>> -----Original Message-----
>>>> From: Mailing List [mailto:[email-masked]] On Behalf Of 
>>>> Paul
>>>> Wells
>>>> Sent: Wednesday, March 08, 2006 6:01 PM
>>>> To: [email-masked]
>>>> Subject: Re: OAPFv3: what is the use of prefixes in Link LSA
>>>>
>>>> Hi Manoj,
>>>>
>>>> Goyal, Manoj wrote:
>>>>
>>>>
>>>>  
>>>>
>>>>> HI,
>>>>>
>>>>> In ospfv3 the intra-area-prefix LSAs have all the prefixes and 
>>>>> routing
>>>>>  
>>>>>     
>>>>
>>>>
>>>> table
>>>>
>>>>
>>>>  
>>>>
>>>>> should be calculated using them. Then what is really the use of 
>>>>> having
>>>>>
>>>>> the prefixes of the link in its link-LSA.
>>>>>  
>>>>>     
>>>>
>>>>
>>>> For broadcast and nbma links, the prefixes in the link lsas are 
>>>> used by
>>>>   
>>>
>>>
>>>
>>>  
>>>
>>>> the DR to construct the intra-area prefix lsa associated with the 
>>>> network lsa.
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>> Is there a case where the router will not include some prefixes in

>>>>> intra-area-prefix LSA
>>>>>
>>>>> but advertise in the link-LSA? I don't see any such case.
>>>>>  
>>>>>     
>>>>
>>>>
>>>> Prefixes for broadcast/nbma transit links are advertised by the DR 
>>>> on behalf of the attached routers, and not by the non-DR routers 
>>>> themselves.  But if you are asking if some of the prefixes won't 
>>>> appear
>>>>   
>>>
>>>
>>>
>>>  
>>>
>>>> in _any_ intra-area prefix lsa, then no, I don't think so.
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>> Thanks,
>>>>>
>>>>> Manoj
>>>>>  
>>>>>     
>>>>
>>>>
>>>> ============================================================
>>>> The information contained in this message may be privileged
>>>> and confidential and protected from disclosure. If the reader
>>>> of this message is not the intended recipient, or an employee
>>>> or agent responsible for delivering this message to the
>>>> intended recipient, you are hereby notified that any reproduction,
>>>> dissemination or distribution of this communication is strictly
>>>> prohibited. If you have received this communication in error,
>>>> please notify us immediately by replying to the message and
>>>> deleting it from your computer. Thank you. Tellabs
>>>> ============================================================
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>> ============================================================
>>> The information contained in this message may be privileged
>>> and confidential and protected from disclosure. If the reader
>>> of this message is not the intended recipient, or an employee
>>> or agent responsible for delivering this message to the
>>> intended recipient, you are hereby notified that any reproduction,
>>> dissemination or distribution of this communication is strictly
>>> prohibited. If you have received this communication in error,
>>> please notify us immediately by replying to the message and
>>> deleting it from your computer. Thank you. Tellabs
>>> ============================================================
>>>
>>>  
>>>
>
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================