Subject: Re: [sunset4] Fwd: New Version Notification for draft-fan-sunset4-router-id-00.txt

From: Karsten Thomann <[email-masked]>
Date: Fri, 04 Jul 2014 22:22:41 +0200

Hi Peng,

some additional comment to the draft as I now had some more time...
The use of the term system id and 32 bit in one sentence is in my opinion a bit problematic as 
system id is an isis term and the sys id of isis is not 32 bit, but up to 48 bit.

Also with some care it should be a possible solution to use the last 32bit (or 
48 for isis) of the IPv6 address and convert them to decimal to generate the initial ID.
I know thats the thing with hex converted "IPs" we already discussed, but this time instead of 
manuelly created ID as a way to create it automatically.

Regards
Karsten

Am Freitag, 27. Juni 2014, 23:00:44 schrieb Fan, Peng:
> Hi Karsten,
> 
> Okay so it is inconvenient at least when we want to get the value of router
> id from an address.
> 
> This discussion does remind me of a saying that mixed notation is not
> suggested... http://www.ietf.org/mail-archive/web/idr/current/msg12901.html
> 
> Best regards,
> Peng
> 
> > -----Original Message-----
> > From: sunset4 [mailto:[email-masked]] On Behalf Of Karsten
> > Thomann
> > Sent: Friday, June 27, 2014 5:24 PM
> > To: Fan, Peng
> > Cc: [email-masked]
> > Subject: Re: [sunset4] Fwd: New Version Notification for
> 
> draft-fan-sunset4-
> 
> > router-id-00.txt
> > 
> > Hi,
> > 
> > The mixed notation can't be used, as it is converted to the hex version
> > automatically and is stored as the /96 case in hex.
> > ping 2001:db8::192.168.0.1
> > Pinging 2001:db8::c0a8:1 with 32 bytes of data:
> > 
> > At least im not aware of a device which stores the IPv6 address in mixed
> > notation, they accept it and convert it to the hex notation in /96, afaik.
> > 
> > Regards
> > Karsten
> > 
> > Am 27.06.2014 10:43, schrieb Fan, Peng:
> > > Hi Karsten,
> > > 
> > > Thanks for the comment, please see reply inline [FP].
> > > 
> > >> I think the solution area should be extended by another possibility
> > >> to
> > > 
> > > embed
> > > 
> > >> IPv4 addresses in v6, as the /96 version has to use the hex version
> > >> of the
> > > 
> > > ID,
> > > [FP] Perhaps we can use the mixed notation, e.g.
> 
> 2001:db8::192.168.255.1?
> 
> > >> the use of a /80 could be used to store them in a format like
> > >> 2001:db8::1921:6825:5001 or 2001:db8::0102:5525:0001.
> > >> If you like to use an even better readable approach you can also use
> > >> a /64
> > > 
> > > for
> > > 
> > >> addresses like 2001:db8::192:168:255:1.
> > > 
> > > [FP] Yes these approaches are quite human-friendly, thanks.
> > > [FP] We can also consider if there is another solution besides address
> > > mapping and other ideas in the draft.
> > > 
> > > Best regards,
> > > Peng
> > > 
> > >> Regards
> > >> Karsten
> > > 
> > > _______________________________________________
> > > sunset4 mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/sunset4
> > 
> > _______________________________________________
> > sunset4 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sunset4
> 
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 7 Jul 2014 19:33:28 +0800

Hi Karsten,

Please see my reply inline [FP], thanks.

From: Karsten Thomann [mailto:[email-masked]] 
Sent: Saturday, July 05, 2014 4:23 AM
To: [email-masked]
Cc: Fan, Peng
Subject: Re: [sunset4] Fwd: New Version Notification for
draft-fan-sunset4-router-id-00.txt

Hi Peng,

The use of the term system id and 32 bit in one sentence is in my opinion a
bit problematic as system id is an isis term and the sys id of isis is not
32 bit, but up to 48 bit.

[FP] I'll remove "system id" if it seems problematic. I guess the ID we are
talking about is most frequently referred to as "router id", so calling it
"router id" is enough, although the device running the protocol is not
necessarily a router.

Also with some care it should be a possible solution to use the last 32bit
(or 

48 for isis) of the IPv6 address and convert them to decimal to generate the
initial ID.

I know thats the thing with hex converted "IPs" we already discussed, but
this time instead of manuelly created ID as a way to create it
automatically.

[FP] Yes. We are actually focusing on two aspects: the generation of unique
IDs and the possibility of binding ID with IP address. If IP address is
planned beforehand, and router ID is not planned but left to admins to
decide, then router ID can be determined using IP address, e.g. using hash
as described in the document, or directly copying part of IP address as you
have suggested (perhaps we can consider it as a simple hash). But it is
possible that the same part of two IP addresses are the same, so we have to
take care when doing this.

Thanks and regards,

Peng 

Regards

Karsten

> suggested...
http://www.ietf.org/mail-archive/web/idr/current/msg12901.html

---

From: "George, Wes" <[email-masked]>
Date: Mon, 28 Jul 2014 11:30:39 -0400

Some quick comments based on my first pass review, all as an individual
not a chair:

Right now, your problem statement is accurate, in that a router with no
defined IPv4 addresses has no way to derive a 32-bit system ID without
further user input, either in the form of a new algorithm or manually
defining the ID. However, if you are asserting that effort should be made
to preserve this link between the two, there needs to be better discussion
of why the value shouldn't be arbitrary (e.g. a 32-bit random number) as
long as it is unique in the scope that it needs to be. Yes, there are some
instances that you've discussed in the introduction where it's marginally
more useful to have the router-id correspond to a value present elsewhere
on the device. However, I don't think you've really defined any specific
problem that this causes, since it is unlikely that the only identifying
information will be the router ID. Are there any places in the UI of
standard routers or in actual data sent on the wire where the only
information presented is the router-id, thus requiring there to be a
correlation between that value and something elsewhere on the router? If
so, it's possible that the underlying problem is that some implementations
are assigning too much contextual value to an arbitrary field, and this
document needs to have guidance to implementers that they should stop
doing this. Either way, we need to get beyond hand-waving, and into more
specific discussion of this problem space.

What we have to do is separate convention (things that were done because
the info was there) from legitimate areas where the lack of this
information and correlation causes extra steps in troubleshooting or
locating a given router. That will in turn drive your solution space - if
there are places where that correlation needs to be preserved, then an
algorithm for deriving IDs from IPv6 addresses in a way that is
human-readable might be necessary. If not, then this is more about
suggesting a couple of suitably random data sources on the router to use
as input to generating a router-ID, possibly in conjunction with a method
to detect and correct duplication within the scope where they must be
unique.

"there has been suggestion about avoiding protocol change" - better
phrased as "protocol change may be unnecessary to address this problem" --
and more to the point, you need to explain what protocol change you're
suggesting is unnecessary (that existing 32-bit ID fields should be
increased to 64 or 128 bit fields or new fields added in order to
accommodate an IPv6 address). This is obvious to me, because I had read
your previous drafts suggesting that solution in the routing WGs, but
should be explicitly stated in this draft for those not familiar with that
background context.

As the problem statement is refined, it may also help us work through the
different scenarios so that we are able to say definitively whether there
are any cases where the value of the router ID is important to the
protocol and thus must be a valid IP address (v4 or v6), and whether or
not there are any gaps where the protocol still needs to be updated to
handle IPv6 addresses as IDs on an IPv6-only network. Those would likely
spawn separate documents in the appropriate protocol's WG.

Thanks,

Wes George

On 6/20/14, 4:34 AM, "Fan, Peng" <[email-masked]> wrote:

>Hi all,
>
>The following draft is about problems of managing router IDs in an
>IPv6 only network as well as some solution ideas. It is an effort
>based on the feedback during the last IETF meeting. Your review and
>comments are appreciated.
>
>Best regards,
>Peng
>
>---------- Forwarded message ----------
>From: [email-masked]
>Date: Fri, 20 Jun 2014 00:50:46 -0700
>Subject: New Version Notification for draft-fan-sunset4-router-id-00.txt
>To: Peng Fan <[email-masked]>
>
>
>A new version of I-D, draft-fan-sunset4-router-id-00.txt
>has been successfully submitted by Peng Fan and posted to the
>IETF repository.
>
>Name:          draft-fan-sunset4-router-id
>Revision:      00
>Title:         Managing Router Identifiers during IPv4 Sunset
>Document date: 2014-06-20
>Group:         Individual Submission
>Pages:         3
>URL:
>http://www.ietf.org/internet-drafts/draft-fan-sunset4-router-id-00.txt
>Status:
>https://datatracker.ietf.org/doc/draft-fan-sunset4-router-id/
>Htmlized:       http://tools.ietf.org/html/draft-fan-sunset4-router-id-00
>
>
>Abstract:
>   This document describes problems of managing protocol identifiers
>   when turning off IPv4 and migrating to IPv6 only network, with some
>   potential solutions discussed.
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.