Subject: Re: OSPFv3 nexthop

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

Hi Sina,

Thanks for restating the points, restating from the first mail I sent.

As nothing prevents us(from the protocol point of view) from using the other
IPv6 addresses, the restriction in section 3.8.1.1

   In IPv6, the calculation of the next hop's IPv6 address (which will
   be a link-local address) proceeds along the same lines as the IPv4
   next hop calculation (see Section 16.1.1 of [Ref1]).

should not be there(which is exactly where I started off from. Saying next
hop IPv6 address will be link-local is wrong).

Do you agree to the above statement?

Thanks,
Vishwas

-----Original Message-----
From: Sina Mirtorabi [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 5:35 PM
To: [email-masked]
Subject: Re: OSPFv3 nexthop

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

>
> 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: Acee Lindem <[email-masked]>
Date: Tue, 3 Dec 2002 09:45:35 -0500

> Do you agree to the above statement?

Hi Vishwas,

I'm not sure I'd agree that the RFC is wrong. The link-local address is
certainly the most straightforward (for the reasons Sina mentions) and
there is certainly some value in having all OSPFv3 implementations calculate
their routes the same way. Also, this text has withstood all the
review cycles.

You could install a global next-hop address and still be compatible.

Thanks,
Acee

--
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 3 Dec 2002 06:47:10 -0800

Vishwas,

> From: Mailing List [mailto:[email-masked]] On
> Behalf Of Manral, Vishwas
> Sent: Tuesday, December 03, 2002 4:21 AM
> As nothing prevents us(from the protocol point of view) from
> using the other IPv6 addresses, the restriction in section 3.8.1.1
>
> should not be there(which is exactly where I started off
> from. Saying next hop IPv6 address will be link-local is wrong).
>

Not really ;-) the question that you have not yet replied to, is that
why should we ever need to change the nexthop to a non-link-local
address for OSPF use ?

The fact that an implementation can put any address as a nexthop does
not mean that RFC need to be changed to not mention explicitly that
nexthop is a link-local

If you put the nexthop to a non-link-local address are you RFC
non-compliant ? I don't think so since nexthop setting is internal to
your router and does not cause any interoperability problem

So let's leave the RFC wording as it is unless there is a case scenario
in which link-local address will Not work for OSPF use ;-)

Sina

> > 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
> 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 ;-)
>
> - 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
>
>
> >
> > Thanks,
> > Vishwas
> >
> > 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.
> >
> >
> > >