Subject: Re: OSPFv3 nexthop

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 2 Dec 2002 07:17:53 -0500

Yasu/Sina/Acee,

Thanks for the discussion.

Firstly let me explain the three statements Sina has quoted from the
draft(which I misconstrued to mean the same Sina did earlier).

      Link-local Interface Address
      The originating router's link-local interface address on the
      link.

Though this clearly means the link LSA can have only link-local address in
the Link-local Interface address field, global/site local prefixes can
always be contained in the  Address prefix field in the same LSA. There is
nothing that prevents it(infact because we are using the term "link-local"
for the constrained field, not using the term for the prefix suggests
clearly that non link-locals could be used in prefixes.

   Link-LSAs have three purposes: 1) they
   provide the router's link-local address to all other routers attached
   to the link and 2) they inform other routers attached to the link of
   a list of IPv6 prefixes to associate with the link and 3) they allow
   the router to assert a collection of Options bits to associate with
   the Network-LSA that will be originated for the link.

This nowhere states that a router cannot have non-link-local addresses in
"Link LSA". Because the link-local address field is compulsary the statement
1) is correct. The point 2) clearly states that it can inform of other
addresses too, by not explicitly prefixing the term link-local.

   A router learns the link-local addresses of all other
   routers attached to its links, and uses these addresses as next hop
   information during packet forwarding.

This statement also does not anyway state that non-link local prefixes
cannot be used, it only states that link-locals are used for nexthop
calculation.

The requirement that I was talking about in my earlier mail wasn't about FA.
I was talking about a case where BGP uses the IGP nexthop to advertize in
its routes, in which case we will require a non-local scope address (and as
Acee put it third-party nexthop)

Thanks,
Vishwas

-----Original Message-----
From: Sina Mirtorabi [mailto:[email-masked]]
Sent: Sunday, December 01, 2002 5:10 PM
To: [email-masked]
Subject: Re: OSPFv3 nexthop

Yasu,

>
> sina> having global address in Link-LSA is irrelevant to next hop
> sina> calculation, the fact of carrying global IPv6 address
> in Link-LSA
> sina> is just related to announcing all global Ipv6 address of a
> sina> multi-access link to DR so that it will announce them in its
> sina> intra-area-prefix LSA
> sina>
> sina> Link-local address is the only address to be always
> available ( as
> sina> Acee said ) therefore this address can always be used to reach
> sina> your nexthop and you should not need any other address
> even a node
> sina> can have multiple IPv6 address

Yasu> Having a global address in Link-LSA (specifically in
Yasu> 'Link-local Interface Address' field) is *not* irrelevant. It
Yasu> will be used as the actual nexthop in SPF calculation.

First of all as its name says "Link-local Interface Address" field
contain a link local address and *Not* a global IPv6 address, it is
clearly mentioned in the RFC

---
Link-local Interface Address
      The originating router's link-local interface address on the
      link.

...

Link-LSAs have three purposes: 1) they
   provide the router's link-local address to all other routers attached
   to the link and 2) they inform other routers attached to the link of
   a list of IPv6 prefixes to associate with the link and 3) they allow
   the router to assert a collection of Options bits to associate with
   the Network-LSA that will be originated for the link.

...

A router learns the link-local addresses of all other
   routers attached to its links, and uses these addresses as next hop
   information during packet forwarding.

----

I think it is clear enough from the above that the global address in the
Link-LSA is used for announcing those prefix to the DR and therefore is
irrelevant to nexthop calculation which use only link-local address;-)

Last we do not really need Link-LSA for nexthop calculation ( as it is
mentioned in the RFC ) except for NBMA, since we would learn them
through Hello reception and the source IPv6 address of this packet *is*
a link-local address

Yasu> It is possible for an implementation to recognize a Link-LSA
Yasu> which has a global-address in 'Link-local Interface Address'
Yasu> field as an invalid Link-LSA. It is just because RFC2740
Yasu> describes that way (or the field name indicates that way).

I don't think so, the filed name says clearly what is the value of this
field otherwise it would have stated that it can be an IPv6 address

Yasu> I agree that if OSPFv3 implementation allows, having global
Yasu> address as nexthop will not be a problem.

Yasu> Route table lookup may ensue further to find link-local
Yasu> address for it, or NDP(or some other L2-L3 address mapping
Yasu> mechanism) will work directly on the global address to derive
Yasu> its corresponding L2 address.

The question is Why should I ever need to set the nexthop to a global
Ipv6 address ? If you tell me that then I would agree that RFC need to
mention that the nexthop can be set to a global IPv6 address.

After all you want to send your packet to your _nexthop_ so your
neighbor link-local address is the Ipv6 address that is always available
and least likely to change

Sina

> sina> If you are referring to FA setting, although if it is
> necessary to
> sina> have a global Ipv6 address for FA setting this address is only
> sina> used to forward a packet to, but this does Not mean that the
> sina> nexthop is the FA. A router while trying to install a
> route to the
> sina> external with FA set needs to just know its nexthop
> which would be
> sina> a link-local address ( even if the ASBR setting the FA
> is directly
> sina> connected to this router )
>
> Agree, FA will be used to derive actual nexthop, which will
> be a link-local address in most cases.
>
> regards,
> yasu
>

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 2 Dec 2002 05:35:51 -0800

Vishwas,

In short : "nothing prevent an implementation to set the nexthop to any
IPv6 address in Link-LSA" even RFC mention that nexthop is a link-local
address

In a bit longer ;-)

Announcing a global IPv6 address for BGP is more a BGP issue than OSPF,
when I redistribute OSPF into BGP and I need to use a third party
nexthop for BGP I can

1) change my OSPF nexthop to global IPv6 address in the Link-LSA and
announce this address for BGP nexthop

2) Look for a global IPv6 address belonging to my OSPF neighbor and set
BGP nexthop to this value without changing OSPF nexthop ( which is
link-local ).

This is more an implementation matter .. I still do not see where we
need to change the nexthop to a global IPv6 address for OSPF use ;-)

I would still argue that global IPv6 address in Link-LSA is for
announcing to DR, and link-local address is the only address needed for
nexthop although nothing prevent an implementation to pick up any IPv6
address in the Link-LSA as nexthop...

Sina

> Firstly let me explain the three statements Sina has quoted
> from the draft(which I misconstrued to mean the same Sina did
> earlier).
>
> Though this clearly means the link LSA can have only
> link-local address in the Link-local Interface address field,
> global/site local prefixes can always be contained in the
> Address prefix field in the same LSA. There is nothing that
> prevents it(infact because we are using the term "link-local"
> for the constrained field, not using the term for the prefix
> suggests clearly that non link-locals could be used in prefixes.
>
> This nowhere states that a router cannot have non-link-local
> addresses in "Link LSA". Because the link-local address field
> is compulsary the statement
> 1) is correct. The point 2) clearly states that it can inform
> of other addresses too, by not explicitly prefixing the term
> link-local.
>
> This statement also does not anyway state that non-link local
> prefixes cannot be used, it only states that link-locals are
> used for nexthop calculation.

>
> The requirement that I was talking about in my earlier mail
> wasn't about FA. I was talking about a case where BGP uses
> the IGP nexthop to advertize in its routes, in which case we
> will require a non-local scope address (and as Acee put it
> third-party nexthop)
>
> Thanks,
> Vishwas
>
>
> 'Link-local
> Yasu> Interface Address' field) is *not* irrelevant. It will
> be used as
> Yasu> the actual nexthop in SPF calculation.
>
> First of all as its name says "Link-local Interface Address"
> field contain a link local address and *Not* a global IPv6
> address, it is clearly mentioned in the RFC
>
> ---
> I think it is clear enough from the above that the global
> address in the Link-LSA is used for announcing those prefix
> to the DR and therefore is irrelevant to nexthop calculation
> which use only link-local address;-)
>
> Last we do not really need Link-LSA for nexthop calculation (
> as it is mentioned in the RFC ) except for NBMA, since we
> would learn them through Hello reception and the source IPv6
> address of this packet *is* a link-local address
>
>
> Yasu> It is possible for an implementation to recognize a
> Link-LSA which
> Yasu> has a global-address in 'Link-local Interface Address'
> field as an
> Yasu> invalid Link-LSA. It is just because RFC2740 describes that way
> Yasu> (or the field name indicates that way).
>
> I don't think so, the filed name says clearly what is the
> value of this field otherwise it would have stated that it
> can be an IPv6 address
>
> Yasu> Route table lookup may ensue further to find link-local address
> Yasu> for it, or NDP(or some other L2-L3 address mapping
> Yasu> mechanism) will work directly on the global address to
> derive its
> Yasu> corresponding L2 address.
>
> The question is Why should I ever need to set the nexthop to
> a global Ipv6 address ? If you tell me that then I would
> agree that RFC need to mention that the nexthop can be set to
> a global IPv6 address.
>
> After all you want to send your packet to your _nexthop_ so
> your neighbor link-local address is the Ipv6 address that is
> always available and least likely to change
>
> Sina
>
>
> > Agree, FA will be used to derive actual nexthop, which will be a
> > link-local address in most cases.
> >
> > regards,
> > yasu
> >
>

---

From: Acee Lindem <[email-masked]>
Date: Mon, 2 Dec 2002 09:01:23 -0500

> need to change the nexthop to a global IPv6 address for OSPF use ;-)

I agree here. OSPFv3 should not install a global nexthop just to
make BGP's job easier when determining whether or not a third party
nexthop can be advertised. How BGP does this is an implementation
matter.

>>>sina> Acee said ) therefore this address can always be used
>>
>>to reach
>>
>>>sina> have a global Ipv6 address for FA setting this
>>
>>address is only
>>

--
Acee