Subject: Re: [OSPF] Question: Intra-area Prefix Lsa

From: "Vivek Dubey" <[email-masked]>
Date: 21 Jun 2006 08:12:11 -0000

Hi Acee,
Pls check tagged with <repviv>

On Tue, 20 Jun 2006 Acee Lindem wrote :
Hi Vivek,

Vivek Dubey wrote:

Hi,
Queries tagged by <vivek> for (3) cases listed below.

1) Case1: Transit Link
----------------------
Draft quote
"Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for PrefixLength, PrefixOptions, and Address Prefix fields"

So prefix can be:
a) Global Ipv6 address (LA bit) i.e global ipv6 address associated   with the link (RFC 4293 ipAddressTable)
b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link   (RFC 4293 ipAddressPrefixTable)
c) Further (a) can be part of (b) or independent (RFC 4293   ipAddressPrefix)

Further while DR builds an intra-area-prefix lsa associated with the network LSA

Draft quote
"the list of prefixes in the link-LSA is copied into the intra-area-prefix-LSA that is being built.  Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied"

<vivek1> Since DR does not use prefixes having NU/LA bit set while         originating intra-area-prefix lsa, why should they be made         part of link lsa originated for the transit link
  
The link-LSA has always included a complete set of prefixes for the link. In the case where
the multi-access network has only one connected router, the prefixes will be advertised
in the intra-area-prefix LSA associated with the router and will be more useful.

<repviv> How are we deciding to set/clear LA bit? Is it Ospf level decision?
         Or is it based on whether global unicast ipv6 address associated with the link is present in "ipAddressTable" 
         (RFC4293)

         So the question is when Ospf says "prefixes for the link" where they belong from as per Ipv6, 
         "ipAddressPrefixTable" OR "ipAddressTable".

         If they belong to "ipAddressTable" (prefix length 128), should LA bit be set?
         If they belong to "ipAddressPrefixTable" (prefix length 0...128), should LA bit be set?

         If above is right, advertising prefixes lying in "ipAddressTable" (i.e LA bit set), in link-lsa
         of multiaccess link (non-stub link), is not useful. Than why to include prefixes with LA bit set?

Note that for all link types other than broadcast and NBMA, the prefixes in the link LSA
are NOT used and the link-LSA could, in fact, be limited to the link-local address. Maybe,
I should document this as an option. I've been somewhat hesitant to provide additional
capabilities in the respin since the purpose is mainly to correct and clarify what is currently
in RFC 2740.

<repviv> Agreed. Only P2MP link type is applicabale for link lsa(s) other than broadcast and NBMA and link-lsa associated 
         with that can be limited to link-local address.

IMHO, we should have deprecated MOSPF which would have gotten rid of the NU and
MC bits. However, there was some opposition to this - perhaps, we will be able to do
it in the future.

<vivek2> If global ipv6 address associated with the link, is not part         of global ipv6 address prefix of the link, how would that be         reachable in the Ospf domain, as DR does not advertise such         prefixes (LA bit set), in the intra-area-prefix LSA
  
A router that has a virtual link is responsible for advertising at least one address with
the LA-bit set in the intra-area-prefix-LSA corresponding to the router. If it is necessary
for this address to be the interface address of a multi-access link, it would be advertised
there. For the other cases where the draft dictates that the LA-bit is set, the DR isn't
applicable (loopback and Point-to-Multipoint interfaces).

2) Case2: P2P link
-------------------
The link prefixes can be:
a) Global Ipv6 address (LA bit) i.e global ipv6 address associated
   with the link (RFC 4293 ipAddressTable)
b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link  (RFC 4293 ipAddressPrefixTable)
c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix)
d) The entry (a) NOT part of prefix (b) above (RFC 4293   ipAddressPrefix being NULL)

<vivek3> Should intra-area prefix Lsa associated with the router         include separate entry for:
  a) Global Ipv6 address (LA bit)
  b) Global Ipv6 Prefix i.e global ipv6 prefix associated with            the link

<vivek4> If (c) above is TRUE, should (a) be included separately or         just (b) would do?
  
For P2P links, the global IPv6 address with the LA-bit set should only be advertised if
it necessary to provide an endpoint for a virtual link. In this case, both the global prefix
and the local address (i.e., /128) should be advertised.

3) Case3: Stub Link
--------------------
The link prefixes can be:
a) Global Ipv6 address (LA bit) i.e global ipv6 address associated   with the link (RFC 4293 ipAddressTable)
b) Global Ipv6 Prefix i.e global ipv6 prefix associated with the link   (RFC 4293 ipAddressPrefixTable)
c) The entry (a) part of prefix (b) above (RFC 4293 ipAddressPrefix)
d) The entry (a) NOT part of prefix (b) above (RFC 4293   ipAddressPrefix being NULL)

<vivek5> Should intra-area prefix Lsa associated with the router         include separate entry for:
 a) Global Ipv6 address (LA bit)
 b) Global Ipv6 Prefix i.e global ipv6 prefix associated with            the link

<vivek6> In (c) above is TRUE, should (a) be included separately or         just (b) would do?
 
Same as P2P links.

Thanks,
Acee

Thanks
Vivek

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Jun 2006 13:45:14 -0400

Hi Vivek,

>Pls check tagged with <repviv>
It would be easier if you used a mail client which quoted your
responses so I didn't have to hunt for the latest :^)

>Queries tagged by <vivek> for (3) cases listed below.
The OSPFv3 specification is the only place where reference is made to the
LA bit. So, I'd say that setting/clearing this bit is solely within the
purview of OSPFv3.

>         with that can be limited to link-local address.
I didn't say that - I said that advertising prefixes other than the 
link-local address
isn't really required for link types other than multiaccess links 
(wheher a DR is
elected). While it might be more efficient to suppress advertisement of the
link-LSA altogether, it wouldn't really be backward compatible to do this
(at least not without a knob), since RFC 2740, section 3.8.1.1 uses the 
link-LSA
to obtain the next-hop for all link types. I'll update the text to say 
advertising
other global prefixes is optionally. This was discussed once before with
Manoj Gopal.

Hope this helps,
Acee

>------------------------------------------------------------------------
>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Jun 2006 16:48:32 -0400

Rather than change the RFC 2740 Link-LSA content, I have
introduced a new interface configation parameter.

LinkLSASuppression
      Indicates whether or not origination of a Link-LSA is suppressed.
      If set to "enabled" and the interface type is not broadcast or
      NBMA, the router will not originate a Link-LSA for the link.   This
      implies that other routers on the link will ascertain the  router's
      next-hop address using a mechanism other than the Link-LSA (see
      Section 3.8.2).  The default value is "disabled" for interface
      types described in this specification.  It is implicitly
      "disabled" if the interface type is broadcast or NBMA.  Future
      interface types MAY specify a different default.

This will satisfy Vivek's and Manoj's concern regarding the unneeded
overhead of Link-LSA while affording full backward compatibility.
For better or worse, this will be in the 10 version of the specification.

Thanks,
Acee

Acee Lindem wrote:

>> "Each IPv6 address prefix that has been configured on Link L is added 
>> to the link-LSA by specifying values for PrefixLength, PrefixOptions, 
>> and Address Prefix fields"
>>
>> So prefix can be:
>> "the list of prefixes in the link-LSA is copied into the 
>> intra-area-prefix-LSA that is being built.  Prefixes having the 
>> NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, 
>> nor should link-local addresses be copied"
>>
>> <vivek1> Since DR does not use prefixes having NU/LA bit set 
>> while         originating intra-area-prefix lsa, why should they be 
>> made         part of link lsa originated for the transit link
>>  
>>         Or is it based on whether global unicast ipv6 address 
>> associated with the link is present in "ipAddressTable"         
>> (RFC4293)
>>  
>>
>>         So the question is when Ospf says "prefixes for the link" 
>> where they belong from as per Ipv6,         "ipAddressPrefixTable" OR 
>> "ipAddressTable".
>>
>>         If above is right, advertising prefixes lying in 
>> "ipAddressTable" (i.e LA bit set), in link-lsa
>> <repviv> Agreed. Only P2MP link type is applicabale for link lsa(s) 
>> other than broadcast and NBMA and link-lsa associated         with 
>> that can be limited to link-local address.
>>  
>>
> (at least not without a knob), since RFC 2740, section 3.8.1.1 uses 
> the link-LSA
>> <vivek2> If global ipv6 address associated with the link, is not 
>> part         of global ipv6 address prefix of the link, how would 
>> that be         reachable in the Ospf domain, as DR does not 
>> advertise such         prefixes (LA bit set), in the 
>> intra-area-prefix LSA
>>

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 22 Jun 2006 10:26:33 +0200

----- Original Message -----
From: "Acee Lindem" <[email-masked]>
To: "Vivek Dubey" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 21, 2006 7:45 PM
Subject: Re: [OSPF] Question: Intra-area Prefix Lsa

> responses so I didn't have to hunt for the latest :^)
Nothing whatsoever to do with OSPF but I do agree; I waste ages trying to work
out who is saying what in some exchanges.

I find that for my e-mail client, the ubiquitous Windows, the key is the
Content-Transfer-Encoding: which, when set to 'quoted-printable', suppresses the
markers.  I totally fail to see the logic in this, I cannot find any way to
alter this behaviour, but when I really care, I edit the incoming e-mail to have
a different Content-Transfer-Encoding -  it is usually doing no more than
including redundant carriage returns - before replying.  (But then I am a
perfectionist:-)

Tom Petch

<snip>

/listinfo/ospf