Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)

From: Dimitry Haskin <[email-masked]>
Date: Tue, 16 Dec 1997 17:42:07 -0500

Hi,

1) It is not necessary to *mandate* that a global scope address be always
present in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI
attribute which is sent between external peers that share a common link.
In certain peering arrangements a border router re-writes the Next Hop
Address with one of its own addresses when disseminating external routes to
internal peers. In such cases it is sufficient to advertise only link-local
scope addresses between external bgp peers and sending a global scope
address in addition to a link-local address serves no purpose and only adds
to administrative burden.

Rewriting the Next Hop Address by border routers has become a quite common
practice in IPv4 BGP deployments and I believe it will be more so in IPv6
since it can make BGP peerings immune to renumbering in peering ASs.

To summarize I request that advertising a global scope address in the Next
Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent
between external peers that share a common link be optional - i.e. a
subject to the peering arrangement.

2) A nit:

>From section 4:

   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
                                           ^^^^^^
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.

"Subnet" should be replaced with "link". To use link-local addresses it is
sufficient to share a link.

Dimitry

At 04:01 PM 12/13/97 PST, Yakov Rekhter wrote:
>Folks,
>
>This is to start the WG Last Call on
>draft-ietf-idr-bgp4-ipv6-00.txt.
>
>The Last Call ends 12/30.
>
>Yakov.
>
>

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 19 Dec 1997 12:40:40 -0500

Let me offer the text that I'd like to have inserted in the draft.
Hopefully it will be more acceptable to all sides in the argument.

"Implementations should be able to support disabling the advertisement of a
global scope address in the Next Hop Network Address field of an IPv6
MP_REACH_NLRI attribute which is sent to an external peer. This capability
should be only used when there is explicit knowledge that the external peer
does not use the global scope next hop address in it operation (e.g.
re-writes the Next Hop Address with one of its own addresses). By default,
a global scope address shall be advertised in the Next Hop Network Address
field of an IPv6 MP_REACH_NLRI attribute."

Dimitry

---

From: Pedro Marques <[email-masked]>
Date: Fri, 19 Dec 1997 14:30:42 -0800 (PST)

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> Let me offer the text that I'd like to have inserted in
    Dimitry> the draft.  Hopefully it will be more acceptable to all
    Dimitry> sides in the argument.

    Dimitry> "Implementations should be able to support disabling the
    Dimitry> advertisement of a global scope address in the Next Hop
    Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute
    Dimitry> which is sent to an external peer.

So what would the nexthop look like ?

  Pedro.

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 19 Dec 1997 18:50:58 -0500

>So what would the nexthop look like ?
In this case in contains a link-local scope address only.  In the default
case both link-local and global addresses are advertised as in your draft.

Dimitry

---

From: Pedro Marques <[email-masked]>
Date: Fri, 19 Dec 1997 16:07:01 -0800 (PST)

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    >>  So what would the nexthop look like ?

    Dimitry> In this case in contains a link-local scope address only.
    Dimitry> In the default case both link-local and global addresses
    Dimitry> are advertised as in your draft.

Personally, I see your proposal as a step backwards as it drives us further
away from what i see as the desirable objective which is to not have 
link local addresses in routing protocols or routing tables.

My suggestion would be to take the discussion on what is essentially an
IPv6 architecture problem to the IPng WG and advance this document to PS.

I would really like to abolish the use of link locals altogether but that
would need approval from the IPng WG also...

  Pedro.

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 19 Dec 1997 20:41:34 -0500

>link local addresses in routing protocols or routing tables.
I don't agree but this is a different subject. In any extend at this point
link-local addresses are required in forwarding tables and therefore in
routing protocols, like it or not.  My proposal does not make this
requirement any more or any less.

>IPv6 architecture problem to the IPng WG and advance this document to PS.
I doubt very much you'll get any where with your architectural disagreement
but you welcome to try. As far as the document is concerned, you can't
remove requirement for the link-local address at this point.  Therefore the
use of global next hop addresses is only limited to what is advertised in
the Next Hop field. The text that I offered does not modify default
behavior that you specified.  It only allows some extra flexibility when it
is *explicitly* known that the advertised global address is not used by
receiving peer in any way.  I belive my request is quite reasonable in the
context of the current architecture.  In the unlikely event that you get to
change the IPv6 architecture, it will be completely different ball game and
all protocol specs will need to be revisited any way.

Dimitry