Subject: Re: [Idr] [v6ops] BGP Identifier

From: Randy Bush <[email-masked]>
Date: Fri, 14 Feb 2014 15:51:34 +0900

> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id
>   "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li,
>   2014-02-12

please no.  if you can not assign a unique four octet integer to each
router in your network, then you have much bigger problems.  and adding
a capability and more complexity to try to patch over your inability to
configure your routers will just compound your problems.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Feb 2014 10:05:48 +0100

I agree with Randy'a point here.

BGP rtr_id does not need to be a routable address - it just needs to be
unique 32 bits within the domain scope.

We have had this discussion already during RFC6286 and concluded that 4
octet is sufficient for any type of BGP mesh.

If anything I would propose to go opposite and to ask your implementation
to allow UTF-8 encoded BGP rtr_id format.

Rgs,
R.

On Fri, Feb 14, 2014 at 7:51 AM, Randy Bush <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jared Mauch <[email-masked]>
Date: Fri, 14 Feb 2014 16:14:28 -0500

On Feb 14, 2014, at 3:13 PM, Sander Steffann <[email-masked]> wrote:

> Hi,
> I agree. It's a shame that the router-id looks like an IPv4 address and IPv4 addresses are used to auto-configure it when the operator doesn't explicitly set it. There are too many people that think that a router-id is more than a 32-bit number and must be an IPv4 address, but creating more complexity to avoid educating router operators isn't the answer...

+1

Perhaps this is another thing like ASDOT vs ASPLAIN where we can shift the configuration on devices to accept a decimal number?

- Jared

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 14 Feb 2014 21:17:09 +0000

+1. 

We had a bit of discussion on MPLS WG ~2yrs ago during LDP-ipv6 formulation and we managed to quickly put the suggestion about LDP router-id being a 128-bit entity in the back burner. 

Good or bad - many vendor implementations historically tied router-id to an interface in addition or instead of a 4-context entity. Thankfully, many have already evolved to not continue with that model in the v6 paradigm. Just a matter of time for others to catch up. 

Cheers,
Rajiv

> On Feb 14, 2014, at 2:13 PM, "Sander Steffann" <[email-masked]> wrote:
> 
> Hi,
> 
> Cheers,
> Sander
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mitchell Erblich <[email-masked]>
Date: Fri, 14 Feb 2014 13:56:29 -0800

For some minor consistency,  

 I think that some LAN protocols prefer a loopback (assume always up) addr and then secondarily an interface addr.

Mitchell Erblich

On Feb 14, 2014, at 1:05 AM, Robert Raszuk wrote:

> BGP rtr_id does not need to be a routable address - it just needs to be unique 32 bits within the domain scope. 
> 
> We have had this discussion already during RFC6286 and concluded that 4 octet is sufficient for any type of BGP mesh. 
> 
> If anything I would propose to go opposite and to ask your implementation to allow UTF-8 encoded BGP rtr_id format. 
> 
> Rgs,
> R.
> 
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 15 Feb 2014 09:09:21 +0900

> I think that some LAN protocols prefer a loopback (assume always up)
> addr and then secondarily an interface addr.

interesting.  and what LAN protocols use the BGP RouterID? 

randy

---

From: Mitchell Erblich <[email-masked]>
Date: Fri, 14 Feb 2014 16:49:05 -0800

Randy

	A router-id is a router-id.

	Do you think that every protocol that is enabled on the router should have a different router-id?

	So, if you have enabled RIP, OSPFv2, OSPFv3, ISIS, BGP, etc, then for consistency basis, I think the router SHOULD have 1 router-id..

	Now… how many implementations have 1 and why shouldn't an admin attempt to have a router with as few router-ids as possible?  Best 1 unique router-id accross all its enabled and not enabled protocols.

	So, if you redistributes OSPF routes into BGP (RFC 1403), wouldn't is be easier to admin with each router having a single router-id?

	Mitchell Erblich

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Feb 2014 20:47:22 -0500

> On Feb 14, 2014, at 7:49 PM, Mitchell Erblich <[email-masked]> wrote:
> 
> Randy
> 

Well, this seems an interesting argument.  This capability is proposed as a problem for IPv6 only networks needing a 128 bit identifier. 

Randy argues for local assignment of 32 bit identifier as sufficient for BGP and you say not good enough for consistency sake you want all protocols to choose the same loopback based number naming 3 protocols that have 32 bit identifiers, 1 protocol with no identifier, and 1 protocol with 48 bit sys-id.  Since RIP is mentioned, why not throw in EIGRP (32 bit) as well, since this supports IPv6 unlike OSPFv2...

So looking at the list I think we can all say for consistency and simplicity across protocols operator should prefer 32 bit values based on local loopback if IPv4 enabled, or 32 bit self administered numbers if IPv6 only so they can keep one identifier recognizable across all protocols for their routers w/o extending every protocol in the list to support 128 bit identifiers...

-Jon

---

From: Shane Amante <[email-masked]>
Date: Fri, 14 Feb 2014 19:58:53 -0800

Hi,

I'm not casting an opinion either way wrt this specific draft; however, I do wish to make two points below.

> I agree. It's a shame that the router-id looks like an IPv4 address and IPv4 addresses are used to auto-configure it when the operator doesn't explicitly set it. There are too many people that thin…

I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology of the router purporting to have said ROUTER_ID.

The other question I would raise is, in a far-off future, if we ever manage to get networks converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?

-shane

---

From: Randy Bush <[email-masked]>
Date: Sat, 15 Feb 2014 17:55:49 +0900

I use this funny thing called DNS. 
-- 
Phones are not computers and suck for email

On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante <[email-masked]> wrote:
>> I agree. It's a shame that the router-id looks like an IPv4 address
>and IPv4 addresses are used to auto-configure it when the operator
>doesn't explicitly set it. There are too many people that think that a
>router-id is more than a 32-bit number and must be an IPv4 address, but
>creating more complexity to avoid educating router operators isn't the
>answer...
>
>I would take exception to a ROUTER_ID being just a 32-bit integer. 
>Specifically, when a ROUTER_ID is an IP address that allows an operator
>to quickly perform diagnosis & troubleshooting using
>ping/traceroute/etc. to identify the availability and location within
>the topology of the router purporting to have said ROUTER_ID.
>
>The other question I would raise is, in a far-off future, if we ever
>manage to get networks converted away from dual-stack and back to a
>single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you
>lose those capabilities mentioned above ... would you care?
>
>-shane

---

From: Shane Amante <[email-masked]>
Date: Sat, 15 Feb 2014 07:13:10 -0800

> I use this funny thing called DNS. 

And that has what to do with the problem of determining liveness or determining where in the topology is a ROUTER_ID?

-shane

> The other question I would raise is, in a far-off future, if we ever manage to get networks
> converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?
> 
> -shane
>

---

From: Shane Amante <[email-masked]>
Date: Sat, 15 Feb 2014 07:53:39 -0800

On Feb 15, 2014, at 7:26 AM, Sander Steffann <[email-masked]> wrote:
> Op 15 feb. 2014, om 16:13 heeft Shane Amante <[email-masked]> het volgende geschreven:
> And what does an integer called ROUTER_ID tell you about that?

In my past experience, I have found that -- particularly in new networks that I'm unfamiliar with -- looking at the output of "show (ospf|isis) database extensive", finding a ROUTER_ID that originated the LSA/LSPDU and performing a ping and/or traceroute to it to verify the sanity of where in the topology that ROUTER_ID is located has been helpful in rapidly diagnosing and fixing brokenness.  Yes, I will admit that it is not a panacea (i.e.: it does not help in the case of duplicate ROUTER_ID's), but 99% of the time it's often using that information to figure out where traffic is, or is not, going to.

Look, it's your network, do whatever pleases you.  But, in networks that I've run, having congruency between the ROUTER_ID and a Loopback address has helped more often than not.

> And hey, you can always create records like
>  1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net

And, when your DNS server is unreachable because you've got a network issue, what then?

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 15 Feb 2014 13:37:46 -0500

> In my past experience, I have found that -- particularly in new networks that I'm unfamiliar with -- looking at the output of "show (ospf|isis) database extensive", finding a ROUTER_ID that origina…

for isis I think unique router-id is important (at least inside the
same level? or perhaps I'm just thinking that changing the router-id
is a ted update event.) but for bgp it seems less important (aside
from the troubleshooting you outline). I imagine it'd actually be nice
to be able to set a router-id externally and a different one
internally actually. This could have some fun implications really...
'my router-id everywhere is 1!' (or zero)

> And, when your DNS server is unreachable because you've got a network issue, what then?

you could, of course, replace 'dns' with any other separated mapping
system (say a text file in the least complex setup). This does add
more work for O&M though, which is probably bad :( extra record
keeping isn't particularly good...

I wonder though what's going to happen if you don't have ipv4 on the
network anylonger, and have no need for ipv4 identifiers? do you just
keep numbering the router-id from "some ipv4 space" or do we have to
look at updating bgp to have a router-id (and isis and ospf and...)
that's more than just 32 random bits that happen to look like an ip
address?

-chris

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 15 Feb 2014 18:49:27 +0000

>   1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net

guys, we're all having a bit of an ietf moment here: within the space of 48
hours, the conversation has ratholed.  Let's love up a bit.

The authors of the draft have a simple operational desire to make their
lives a little easier and as an operator I sympathise with this,
particularly because they are using ipv6-only networks in anger which is
more than I do.

There are two advantages of having a 128 bit router-id (with the unstated
convention of tying router-id == address of first loopback):

- firstly it's easy to identify the location of prefix announcements on
your network
- secondly the router-id can be autoconfigured.

On the other hand, implementing this will require that the authors define a
transition mechanism to allow 128 bit router-id routers interoperate with
32 bit router-id routers in such a way that router-id collisions don't occur.

If the authors want to progress this, they need to state a stronger use
case and they need to create a transition mechanism.  If they can do this
in a reasonable way which doesn't break backwards compatibility, then it
might be appropriate for idr / v6ops / etc to take another look at the draft.

Also, I wish them well because everyone understands what a router ID is and
everyone will want to paint theirs a different colour.

Nick

---

From: David Farmer <[email-masked]>
Date: Sat, 15 Feb 2014 13:25:59 -0600

> On Feb 14, 2014, at 21:58, Shane Amante <[email-masked]> wrote:
> 

I agree it is a very common and useful operational practice to use the IPv4 loopback address for the ROUTER_ID.  This practice is strongly reinforced in that most implementations represent the ROUTER_ID in dotted quad decimal notation, the same way we represent IPv4 addresses.

However, common practice does not make it a protocol requirement.  I would suggest there are several possible new operational practices that could be developed that don't require complicate changes to the protocol.  

A very simple one would be to use a common IPv6 prefix for all your /128 IPv6 loopback addresses and embed the ROUTER_ID as the least significant 32 bits.  Just as implementations reinforce the current operational practice, they could also reinforce this possible new practice by representing the 32bit ROUTER_ID in hex instead of dotted quad decimal, or even better both representations next to each other.  Maybe implementations could allow you to specify a /96 IPv6 prefix to be appended with the ROUTER_ID when it is output, giving you the IPv6 address you wanted without changing the protocol.

As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205.  Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or you could even used mixed notation 2001:db8:1::192.0.2.5.

So, you do not loose the ability to "quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology."

There was also a DNS recommendation made in the thread, that would work too.

So, I'd prefer effort be put toward an informational draft suggesting operational practices and maybe implementation suggestions that reinforce these suggestions rather than complicated protocol changes.  

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 17 Feb 2014 00:28:32 +0800

Hi Randy, and all,

Thanks for the discussion and sorry for the late. Assigning an id is not a
difficult issue, especially on a single router. But what number is to be
assigned might be an issue, especially in an ISP's large network, in order
to guarantee the uniqueness of the ids. In our network this kind of numeric
resources, e.g. IP addresses and cell phone numbers, is planned in advance
(usually with a careful designed numbering rule), and then delivered to
admins who located at different parts of the network. In the IPv4 world, we
take advantage of an IPv4 address, as it by nature an ideal id and fits into
the 32-bit length, and could be helpful in OAM. So perhaps we can use a
similar approach in an IPv6-only world, then the admins don't have to bother
to worry how to choose the ids. An id is not necessarily an IP address, but
IP address is a perfect candidate for an id.

Thanks and regards,
Peng

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Friday, February 14, 2014 2:52 PM
> To: Fred Baker
> Cc: idr wg; V6 Ops List
> Subject: Re: [Idr] [v6ops] BGP Identifier
> 
router in
> your network, then you have much bigger problems.  and adding a capability
> and more complexity to try to patch over your inability to configure your
routers
> will just compound your problems.
> 
> randy
>

---

From: Sander Steffann <[email-masked]>
Date: Fri, 14 Feb 2014 21:13:18 +0100

Hi,

Cheers,
Sander

---

From: Owen DeLong <[email-masked]>
Date: Fri, 14 Feb 2014 15:01:07 -0800

On Feb 14, 2014, at 12:13 PM, Sander Steffann <[email-masked]> wrote:

> I agree. It's a shame that the router-id looks like an IPv4 address and IPv4 addresses are used to auto-configure it when the operator doesn't explicitly set it. There are too many people that think that a router-id is more than a 32-bit number and must be an IPv4 address, but creating more complexity to avoid educating router operators isn't the answer…

+1

Owen

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 12:15:20 +0100

> I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping…

If you try to ping a router-id then all bets are off. I have seen too many cases with misconfigured router-ids to attach any value (except the numerical one) to them. I also never try to ping OSPF area numbers ;)

> The other question I would raise is, in a far-off future, if we ever manage to get networks converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bit…

Not at all. And it I wanted to link IPv6 loopback addresses and router-ids I probably would choose a router-id (say aaa.bbb.ccc.ddd) and then use either 2001:db8::aaa.bbb.ccc.ddd/128 or 2001:db8::aaa:bbb:ccc:ddd/128 as loopback address.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 16:26:11 +0100

:-)

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 21:58:17 +0100

Hi David,

> So, you do not loose the ability to "quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology."

Yeah, this sounds about right :)

> So, I'd prefer effort be put toward an informational draft suggesting operational practices and maybe implementation suggestions that reinforce these suggestions rather than complicated protocol ch…

I fully agree. I'd be willing to help write such a draft.

Cheers,
Sander

---

From: Owen DeLong <[email-masked]>
Date: Sat, 15 Feb 2014 13:31:16 -0800

If nothing else, if the authors intend to apply this to more routing protocols than just BGP, they should change the proposal to reflect that they seek to change ROUTER-IDs in general and not just the BGP identifier.

However, I believe that the idea of converting a router-id from 32 bits to 128 bits is woefully misguided. I say this as an operator who has operated IPv4 and IPv6 and dual-stack networks.

It has always, IMHO, been unfortunate that OSPF Area numbers and Router-IDs for various protocols have been tied to IPv4 address syntax and, in the case of router-IDs, affiliated with interface (including loopback) IP addresses. This has created no end of confusion among less well trained operators.

IPv6 gives us the opportunity to correct this problem and have IDs which no longer match addresses. That is a "good thing™" IMHO.

As near as I can tell, this draft seeks to prevent that improvement from occurring.

Instead, I think that Sander and David are on a much better track and I would be willing to join in on the efforts to write such an operational draft.

Owen

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Feb 2014 09:45:07 +0800

> to guarantee the uniqueness of the ids.

as i said, if you can not assign unique 32 bit integers to your routers,
you have far bigger problems in your organization and network.  and
having them be 128 bit integers is not going to solve your problems.

randy

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 17 Feb 2014 10:51:26 +0800

Hi Randy,

Just to clarify. I am not complaining we cannot assign the unique integers,
but the integers require additional planning, and that from operational
perspective causes inconvenience. Following the experience in ipv4 enabled
network would be a natural thought, especially when you want the IDs to be
helpful in troubleshooting rather than just pure numbers.

Peng

> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, February 17, 2014 9:45 AM
> To: Peng Fan
> Cc: idr wg; V6 Ops List
> > Thanks for the discussion and sorry for the late. Assigning an id is
> > not a difficult issue, especially on a single router. But what number
> > is to be assigned might be an issue, especially in an ISP's large
> > network, in order to guarantee the uniqueness of the ids.
> 
you have far
> bigger problems in your organization and network.  and having them be 128
bit
> integers is not going to solve your problems.
> 
> randy

---

From: Shane Amante <[email-masked]>
Date: Sun, 16 Feb 2014 21:39:32 -0800

Hi David,

> So, I'd prefer effort be put toward an informational draft suggesting operational practices and maybe implementation suggestions that reinforce these suggestions rather than complicated protocol ch…

I agree and would be willing to help draft text and/or review such a draft.

-shane

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Feb 2014 10:24:52 +0100

Hi Peng,

Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet
router_id in IPv6 only network?

No protocol changes needed :)

r.

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 17 Feb 2014 18:10:57 +0800

Hi Robert,

Yes that is a possible solution for troubleshooting, once the router_id has
been determined. But how do you determine at first the value of a.b.c.d when
there is no ipv4 address to be referred to, especially in an automatic
manner? Beforehand planning work for the ids for the entire network is
something I am concerned with :)

Regards,

Peng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
Raszuk
Sent: Monday, February 17, 2014 5:25 PM
To: Fan, Peng
Cc: Randy Bush; idr wg; V6 Ops List
Subject: Re: [Idr] [v6ops] BGP Identifier

Hi Peng,

r.

Hi Randy,

Peng

you have far
bit

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Feb 2014 11:13:21 +0100

Hi,

> something I am concerned with :)

How do you plan transit network and loopback IP assignment?

See, it's quite doable.

(Assign loopback addresses in a way that you can use the last 32 bits as 
router ID, done)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Feb 2014 18:25:40 +0800

> something I am concerned with :)

all your comments are symptoms of the insanity of trying to configure a
large network manually.  this went out of fashion in the last century,
and we do not try to compensate for insanity through protocol
modification.

randy

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 17 Feb 2014 22:16:00 +0800

Hi Gert,

I see your point. We use a hierarchy in operating a large network, for
example the headquarter assigns an address block to a province, and the
province assigns a sub-block to a city, and administrators in the city
assigns an address to a router. We cannot require an admin to assign an
address with a unique id as they don't know what others use for ids.
Operating the entire network by a single person would be easy but we can
rarely see this case.

Peng

> From: Gert Doering [mailto:[email-masked]]
> Sent: Monday, February 17, 2014 6:13 PM
> To: Fan, Peng
> Cc: 'Robert Raszuk'; 'idr wg'; 'V6 Ops List'
> Subject: Re: [v6ops] [Idr] BGP Identifier
> 
> Hi,
> 
> > Yes that is a possible solution for troubleshooting, once the
> > router_id has been determined. But how do you determine at first the
> > value of a.b.c.d when there is no ipv4 address to be referred to,
> > especially in an automatic manner? Beforehand planning work for the
> > ids for the entire network is something I am concerned with :)
> 
router ID,
> done)

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 17 Feb 2014 22:16:07 +0800

Randy,
Would you please give me an example about how modern large ISPs manage their
networks?

> Sent: Monday, February 17, 2014 6:26 PM
> To: Fan, Peng
large
> network manually.  this went out of fashion in the last century, and we do
not
> try to compensate for insanity through protocol modification.
> 
> randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Feb 2014 22:50:18 +0800

> Would you please give me an example about how modern large ISPs manage their

programmatic generation of configurations from databases.

randy

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 17 Feb 2014 15:52:53 +0000

We endeavor to automate as much as possible as manual/human manipulation usually results in a big error at some point..

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Monday, February 17, 2014 5:26 AM
To: Fan, Peng
Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'
Subject: Re: [Idr] [v6ops] BGP Identifier

randy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 17 Feb 2014 10:59:51 -0500

http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf

Mike's presentation (given by vijay) is a decent start...

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 12:28:24 -0800

On 2/15/14, 11:25 AM, David Farmer wrote:

> As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205.
> Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or
> you could even used mixed notation 2001:db8:1::192.0.2.5.

You could, but you shouldn't whether it's merely shorthand or not
because ipv6 mapped ipv4 addresses and accompanying notation are are
sort of ugly representation that will be throwing junior network
operators under the bus for years to come.

http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Feb 2014 17:20:06 -0600

> http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00

I'd prefer to recommend that implementations include a hex 
representation of the ROUTER_ID, either in addition to or instead of the 
dotted quad decimal representation.  I need to study it more closely, 
but I think what I'm suggesting is compatible with the recommendation in 
RFC5952 Section 5. However, I take your point, even if compatible with 
RFC5952 Section 5, its best to avoid the problem if possible.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 10:31:57 +0800

Hi Randy,
Do you have such tools to config your network? Or do you know the vendor that provide such tools?Indeed, such programmatic generation tools are good for network plan. But the logic in the tools is complecated especially for a very large network with hierarchical operation as Peng Fan mentioned.

Zhenqiang Li

 From: Randy BushDate: 2014-02-17 22:50To: Fan, PengCC: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'Subject: Re: [Idr] [v6ops] BGP Identifier> Would you please give me an example about how modern large ISPs manage their

randy

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 10:33:09 +0800

Yes we do if we could.

Zhenqiang Li

 From: UTTARO, JAMESDate: 2014-02-17 23:52To: Randy Bush; Fan, PengCC: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'Subject: Re: [Idr] [v6ops] BGP IdentifierWe endeavor to automate as much as possible as manual/human manipulation usually results in a big error at some point..
 
Jim Uttaro
 
-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Monday, February 17, 2014 5:26 AM
To: Fan, Peng
Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'
Subject: Re: [Idr] [v6ops] BGP Identifier

 
randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Feb 2014 10:40:13 +0800

> Do you have such tools to config your network? Or do you know the
> vendor that provide such tools?Indeed, such programmatic generation
> tools are good for network plan. But the logic in the tools is
> complecated especially for a very large network with hierarchical
> operation as Peng Fan mentioned.

there are products in the space, but the large providers i know who
configure programatically developed their own.  there are not enough
large providers not suffering from 'not invented here' to make a
reasonable customer base for serious software development.

but it pays for itself, so smart folk who develop it.

randy

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 10:45:07 +0800

Thank you very much, Mr. Morrow.
Yes, it is a good start. I will contact Vijay for detail. However, I do not see the function that we want from the slides. In fact, we also use some tools to assist our network plan. However, the tools can not satisfy such complex requirement. In a hierarchical operation network, the tools to implement the logic we want is not a easy job.
Zhenqiang Li

 From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP Identifierhttp://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 10:51:37 +0800

Tell me please the large provider that you know has his own automatic configuration tools. I would like to contact him to learn from him. 

[email-masked]
 From: Randy BushDate: 2014-02-18 10:40To: [email-masked]: fanpeng; 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'Subject: Re: [Idr] [v6ops] BGP Identifier> Do you have such tools to config your network? Or do you know the

 
randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Feb 2014 11:17:11 +0800

> Tell me please the large provider that you know has his own automatic
> configuration tools.

l(3), ntt, ...

> I would like to contact him to learn from him. 

it is considered secret sauce

randy

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 11:33:44 +0800

So I have to learn to program now. I hope we could develop our own tools.

[email-masked]
 From: Randy BushDate: 2014-02-18 11:17To: [email-masked]: fanpeng; 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'Subject: Re: [Idr] [v6ops] BGP Identifier> Tell me please the large provider that you know has his own automatic
 
l(3), ntt, ...

 
randy

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 19:55:00 -0800

On 2/17/14, 6:45 PM, [email-masked] wrote:
> 
> 
> 
> 
> 
> 
> Thank you very much, Mr. Morrow. Yes, it is a good start. I will
> contact Vijay for detail. However, I do not see the function that we
> want from the slides. In fact, we also use some tools to assist our
> network plan. However, the tools can not satisfy such complex
> requirement. In a hierarchical operation network, the tools to
> implement the logic we want is not a easy job. Zhenqiang Li

We allocate ipv4 addresses today presumably, which implies the existence
of business logic in basically all isps that accounts for the hierarchic
allocation of 32 bit numbers.

A brief cruise over to

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

Reveals a pool of  at least 28 bits (a /4 in ipv4 land) worth of 32bit
numbers that will never overlap with ipv4 unicast address assignments
that you traditionally use for router-ids. embedding those in family iso
addresses if you like seems harmless and you'll never accidentally
configure one as a unicast address on an interface. it'll be a little
while before I need 268 million bgp speaking routers in the same AS.

> 
> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr
> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP
> Identifierhttp://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf
>
>>> Would you please give me an example about how modern large ISPs
>>> manage their networks?
>> 
>> _______________________________________________ Idr mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________ Idr mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
> 
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 20:21:17 -0800

On 2/17/14, 8:12 PM, George Michaelson wrote:
> 240/4 had drafts against it. NEVER is alas, not a normative word in what
> Joel said.

I was refering to 224/4 which has a fairly toxic property with respect
to it's reuse as ipv4 unicast...

> Juniper already includes a flag to use 240/4 in cloud, at the request of a
> cloud services company.

yup...

> 
> On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli <[email-masked]> wrote:
> 
>>> Identifierhttp://
>> www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf
>>>

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Feb 2014 12:43:46 +0800

> but the integers require additional planning

but 32 bit integers should require only 1/4 the planning as 128 bit
integers :)

you allocate v4/v6 addresses hierarchically.  so take 240/whatever and
allocate using the same system.

randy

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 18 Feb 2014 14:09:30 +0800

Hi Christopher,

Normally it is easier to handle routers within the AS as we have full
control over it. I think the key point is the ASBR, as we have no control of
its eBGP peers. A simple approach is to enable both this extension and
RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup
purpose before we are aware of the capability of its peers. The ASBR prefers
the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero,
which will result in a "bad bgp identifier" error message sent by the peer
if it does not support the new 128-bit ID capability, the ASBR will know the
type of its peer. The ASBR can initiate a second connection in the old way,
and the connection falls back using 32-bit ID.

Peng

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Christopher Morrow
> Sent: Tuesday, February 18, 2014 11:42 AM
> To: [email-masked]
> Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng;
idr
> wg; V6 Ops List
> Subject: Re: Re: [Idr] [v6ops] BGP Identifier
> 
> On Mon, Feb 17, 2014 at 10:30 PM, [email-masked]
> <[email-masked]> wrote:
> > Hi All,
> >
> > Thank you all for your valuable comments and interests in this draft.
> > Any technical concerns about the draft? Is there someone in the mail
> > list from operators that has the same problem as me?
> >
> 
> i think shane's point about 'make a stab at transition technique'
> still needs to be dealt with, yes?
> 
> and really... I don't see a huge reason to do this anyway, yet.
> 
> > Many Thanks,
> > Zhenqiang Li
> >
> > ________________________________
> >

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Feb 2014 14:08:17 +0800

Christopher Morrow <[email-masked]>
Farmer <[email-masked]>
jaeggli <[email-masked]>
Amante <[email-masked]>
JAMES <[email-masked]>
Doering <[email-masked]>
	
> control over it. I think the key point is the ASBR, as we have no
> control of its eBGP peers. A simple approach is to enable both this
> extension and RFC6286, and assign a 32-bit ID in addition to the
> 128-bit one for backup purpose before we are aware of the capability
> of its peers. The ASBR prefers the 128-bit ID. Since the ID field of
> OPEN message sent by the ASBR is zero, which will result in a "bad bgp
> identifier" error message sent by the peer if it does not support the
> new 128-bit ID capability, the ASBR will know the type of its
> peer. The ASBR can initiate a second connection in the old way, and
> the connection falls back using 32-bit ID.

what we have here is a bunch of network operators trying to help you
design and configure your network.  it may have gone past the amusing
and educational for the non-op ietf folk on these lists.  you may get
wider and deeper free consulting, with 42 conflicting opinions, by
moving this to nanog, apops, ... list(s).

randy

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 18 Feb 2014 11:27:16 +0000

We have developed numerous configuration tools that create/mod PE, RR configs. We also have lots of tools that speak to the network in a live sense to get health, stats ... All of the raw material is readily available. TBH I cannot speak to you about our solutions in anymore depth..

Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 17, 2014 9:52 PM
To: Randy Bush
Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'
Subject: Re: [Idr] [v6ops] BGP Identifier

________________________________
[email-masked]<mailto:[email-masked]>

From: Randy Bush<mailto:[email-masked]>
Date: 2014-02-18 10:40
To: [email-masked]<mailto:[email-masked]>
CC: fanpeng<mailto:[email-masked]>; 'idr wg'<mailto:[email-masked]>; 'V6 Ops List'<mailto:[email-masked]>; 'Robert Raszuk'<mailto:[email-masked]>
Subject: Re: [Idr] [v6ops] BGP Identifier

randy

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 19:36:26 +0800

Thank you very much for your information, Jim.We also have some tools to help us to plan and operate our networks. However at present none of the tools can satisfy the requirment of this draft.
Anyway, you do not think it is a problem to plan the 32-bit BGP ID for a very large scale IPv6-only network?

[email-masked]
 From: UTTARO, JAMESDate: 2014-02-18 19:27To: [email-masked]; Randy BushCC: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'Subject: RE: [Idr] [v6ops] BGP Identifier

We have developed numerous configuration tools that create/mod PE, RR configs. We also have lots of tools that speak to the network in a live sense to get health,
 stats … All of the raw material is readily available. TBH I cannot speak to you about our solutions in anymore depth..
 
Jim Uttaro

From: Idr [mailto:[email-masked]]
On Behalf Of [email-masked]

To: Randy Bush

 

 

 

From: Randy
 Bush

Date: 2014-02-18 10:40

CC: fanpeng;
'idr wg'; 'V6 Ops List';
'Robert Raszuk'

 

 

 

randy

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 18 Feb 2014 11:30:59 +0800

Hi All,
Thank you all for your valuable comments and interests in this draft. Any technical concerns about the draft? Is there someone in the mail list from operators that has the same problem as me?
Many Thanks,Zhenqiang Li

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 17 Feb 2014 22:41:54 -0500

On Mon, Feb 17, 2014 at 10:30 PM, [email-masked]
<[email-masked]> wrote:
> Any technical concerns about the draft? Is there someone in the mail list
> from operators that has the same problem as me?
>

---

From: George Michaelson <[email-masked]>
Date: Tue, 18 Feb 2014 14:12:16 +1000

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 18 Feb 2014 13:28:10 +0800

Hi Christopher,

Peng

idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Feb 2014 11:06:39 -0500

On Tue, Feb 18, 2014 at 01:28:10PM +0800, Fan, Peng wrote:
> purpose before we are aware of the capability of its peers.

I am not in favor of this draft.  While I understand the operational desire
for it, what the routing protocols (not just BGP) require is just some magic
number to be used to identify various protocol properties tied to a given
router.  I don't think we want to see a series of similar drafts updating
every other protocol in an attempt to realize a consistent 128 bit router id
throughout an AS.

The fact that this number has been able to receive a mapping to a real
address has been extremely operationally useful.

What I would instead suggest is finding a mechanism by which the unique
router-ID can be mapped easily to such addresses.  I don't believe that BGP is
the right place to do this.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Tue, 18 Feb 2014 12:13:54 -0500

> it is considered secret sauce

we (ntt) have presented about this automation in the past.

google comes up with a few of these:

http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf
http://www.us.ntt.net/news/viewFile.cfm/NTT_Editorial_Capacity_Magazine_nov_2013.pdf?file_id=144
http://ptt.br/pttforum/7/doc/ptt_forum7_morris.pdf

- Jared

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Feb 2014 10:19:51 +0800

Thank you very much, Jared. I will study all the material.

Zhenqiang Li

[email-masked]
 From: Jared MauchDate: 2014-02-19 01:13To: Randy BushCC: [email-masked]; idr wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP Identifier 

 

- Jared

---

From: Shane Amante <[email-masked]>
Date: Wed, 19 Feb 2014 10:41:24 -0800

+1

-shane

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Feb 2014 10:35:45 +0800

> What I would instead suggest is finding a mechanism by which the
> unique router-ID can be mapped easily to such addresses.  I don't
> believe that BGP is the right place to do this.

we need a name to address mapping mechanism.  let's all think about
that.  </sarcasm>

randy

---

From: joel jaeggli <[email-masked]>
Date: Sun, 23 Feb 2014 16:46:53 -0800

> we need a name to address mapping mechanism.  let's all think about

routerid rr-type anyone?

that actually doesn't sound like a totally appalling idea.

:p

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Feb 2014 10:08:36 -0500

> that actually doesn't sound like a totally appalling idea.

The idea of requiring DNS to be working as a tool to manage your routing
plane seems rather abhorrent to me.  If routing isn't working well, neither
will DNS.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Feb 2014 16:18:11 +0100

Jeff,

Even outside of BGP router_id topic for operational reasons resolving
router's IP addresses (especially those v6) to hostnames and to
interface names of the routers in anyone network would seem to me like
rather a useful idea. And that not on a dedicated management linux
station but on all routers.

When you do show command do you prefer to see bunch of digits or much
less and more meaningful ASCII strings ?

Here you have a choice .. flood it by all protocols or push local
hosts files. Since config is automated I do not see much issue in keep
up to date hosts file of your network on all boxes.

Thx,
r.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Feb 2014 10:51:27 -0500

Robert,

> up to date hosts file of your network on all boxes.

I said DNS, not hosts files.

Of course it's possible that rr-types are a more host-file like mechanism
than they used to be.

-- Jeff