Subject: Re: OSPFv3 nexthop

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 3 Dec 2002 00:04:07 -0500

Hi Acee/Sina,

I agree to your points.

Let me restate my original question. As the Link LSA can have any IPv6
address in the Link-LSA, why is there an explicit restriction that the next
hop can only be link-locals? Are there any advantages of having Link-local
for nexthops over others?

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Monday, December 02, 2002 7:31 PM
To: [email-masked]
Subject: Re: OSPFv3 nexthop

Sina Mirtorabi wrote:
> 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 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.

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

--
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 3 Dec 2002 04:04:37 -0800

Vishwas,

>
>
> Hi Acee/Sina,
>
> I agree to your points.
>
> Let me restate my original question. As the Link LSA can have
> any IPv6 address in the Link-LSA, why is there an explicit
> restriction that the next hop can only be link-locals?

As previously stated, nothing prevent an implementation to use any IPv6
address in Link-LSA. As a matter of the fact you can set the nexthop to
what ever you want as long as you know how to deliver the packet to your
next hop ;-)

> Are there any advantages of having Link-local for nexthops over
others?

- link-local address is always available
- least likely to change
- If a non-local address is used, you may end up doing an extra-look up
- since all OSPF packet use link-local as a source of IPv6 address you
have already your layer3/layer2 mapping done and do not need any extra
mapping for this new nexthop

Sina

> > 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
> >
> > 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 ).
> >
> 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.
>
>
> >
> > 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
> >
> >
> >
> >>Yasu/Sina/Acee,
> >>
> 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.
> >>
> >>   provide the router's link-local address to all other routers
> >>attached
> the link
> >>of
> >>   a list of IPv6 prefixes to associate with the link and 3) they
> >>allow
> >>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
> >>
> >>
> >>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
> >>
> >>---
> >>   provide the router's link-local address to all other routers
> >>attached
> the link
> >>of
> >>   a list of IPv6 prefixes to associate with the link and 3) they
> >>allow
> 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
> >>
> >>
> >>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
> >>
> >>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
> >>
> >>
> >>