-----邮件原件-----
发件人: Isis-wg [mailto:[email protected]] 代表 Karsten Thomann
发送时间: 2014年5月9日 16:58
收件人: Xuxiaohu; Anton Smirnov
抄送: [email protected]; George, Wes; [email protected]; joel jaeggli;
OSPF List; [email protected]; [email protected]
主题: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
Hi Xiaohu,
I think I've understand your problem now, but please don't call it a Router ID,
the
router ID must not be an IP address.
To avoid any confusion about it please call it a router ip or router address
within
the TLV.
Please correct me if I'm wrong, but if I understand your drafts right you're not
requesting a real IPv6 Router ID instead of the (arbitrary) 32bit ID, but a
simple
TLV to carry the routable IPv6 address of the router which advertises the
capability.
If I understand it right, we should maybe fix the text of the other rfc to
refect
that it is an routable IP address, instead of a (possible) arbitrary but unique
Router ID.
Kind regards
Karsten
Am 09.05.2014 02:53, schrieb Xuxiaohu:
Hi Anton,
When ISIS capability TLVs are flooded across areas, routers in one area may
need to establish correlations between IP addresses and capabilities of routers
in
another area. For example, assume IS-IS router A in one area has established a
L3VPN session with IS-IS router B in another area. When router A needs to send
L3VPN traffic to router B via a MPLS-SR tunnel, router A wants to know whether
router B (identified by an IP address) has the ELC
(http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before inserting an EL
into
the MPLS-SR packet. In such case, it needs to contain at least one routable IP
address in the capability TLV which has been flooded across area boundaries. In
the IPv4 network, the 4-octect router ID field could contain such routable IPv4
address. However, in the IPv6 network, there is no counterpart field to contain
a
routable IPv6 address.
Best regards,
Xiaohu
-----邮件原件-----
发件人: Anton Smirnov [mailto:[email protected]]
发送时间: 2014年5月8日 22:49
收件人: Xuxiaohu
抄送: [email protected]; George, Wes; [email protected]; joel
jaeggli; OSPF List; [email protected]; [email protected]
主题: Re: [OSPF] 答复: 答复: [Isis-wg] [sunset4] IPv6 router IDs
Hello Xiaohu,
this whole thread started from George Wes stating that even in
pure
IPv4 world Router ID in many protocols is NOT an IPv4 address. For
convenience it frequently is but on the binary scale "ID guaranteed
to be routable IPv4 address"/"ID is just a number" - the Router ID is NOT an
IPv4 address.
So, before you convince people that IPv6 Rtr ID is needed you
must start from discussing when and why Router ID is being used as
IPv4 address in pure
IPv4 world. I believe this in other words is what Acee asking you.
Anton
On 05/07/2014 03:10 AM, Xuxiaohu wrote:
Hi Acee,
The motivation for these two drafts
(http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and
http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very
simple: the
IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for advertising
router capabilities can be flooded across areas, however, only a
4-octect router ID is carried in them. As a result, it’s hard for
routers in one area to establish correlations between IPv6 addresses and
capabilities of routers in another area.
For example, assume IS-IS router A in one area has established a
L3VPN session with IS-IS router B in another area over their own IPv6
addresses. When router A needs to send L3VPN traffic to router B via
a MPLS-SR tunnel, router A wants to know whether router B has the ELC
(http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before
inserting an EL into the MPLS-SR packet . However, the Capability TLV
originated by router B doesn’t carried an IPv6 address of its own. As a result,
it !
s hard fo
r router A to know the ELC of router B.
Best regards,
Xiaohu
-----邮件原件-----
发件人: Acee Lindem [mailto:[email protected]]
发送时间: 2014年5月6日 21:14
收件人: Xuxiaohu
抄送: joel jaeggli; Acee Lindem; George, Wes; [email protected]; OSPF
List; [email protected]; [email protected];
[email protected]
主题: Re: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
On May 5, 2014, at 9:48 PM, Xuxiaohu <[email protected]> wrote:
-----邮件原件-----
发件人: Isis-wg [mailto:[email protected]] 代表 joel jaeggli
发送时间: 2014年5月5日 23:55
收件人: Acee Lindem; Xuxiaohu; George, Wes
抄送: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
主题: Re: [Isis-wg] [sunset4] IPv6 router IDs
On 5/5/14, 9:28 AM, Acee Lindem wrote:
Xiaohu – what are precisely the situations that you think you
need this
IPv6 address?
Acee
if you're using router-id's as equivalency as an ipv4 unicast addresses.
you're doing so at your peril because there is zero assurance
that those actually map. the first time you have a router id of
11100000000000000000000000000101 well bummer.
The IPv6 router ID sub-TLV of the ISIS router capability TLV must
carry a
"routable" IPv6 address. If the name of the sub-TLV seems
confusing, it can be changed to IPv6 address sub-TLV.
Independent of what you call it, you didn’t answer my question.
Other than TE, what the use cases where it is needed?
Acee
Best regards,
Xiaohu
I don't find the embedding of semantic meaning in router-ids to
be more compelling then it was in ip addresses.
From: Xuxiaohu <[email protected]
<mailto:[email protected]>>
Date: Sunday, May 4, 2014 1:29 AM
To: "George, Wes" <[email protected]
<mailto:[email protected]>>
Cc: OSPF - OSPF WG List <[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
Subject: Re: [Isis-wg] [sunset4] IPv6 router IDs
Hi Wes,
Thanks for pointing out these two drafts.
The motivation for these two drafts
(http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and
http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is
very
simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which are used
for
advertising router capabilities can be flooded across areas,
however, only a 4-octect router ID is carried in them. As a result,
it’s hard for routers in one area to establish correlations
between
IPv6 addresses and capabilities of routers in another area. For
example, assume IS-IS router A in one area has established a
L3VPN
session with IS-IS router B in another area over their own IPv6
addresses. When router A needs to send L3VPN traffic to
router B
via
a MPLS-SR tunnel, router A wants to know whether router B
has
the
ELC (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before
<http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)%20before>
inserting an EL into the MPLS-SR packet . However, the
Capability
TLV originated by router B doesn’t carried an IPv6 address of its
own. As a result, it’s hard for router A to know the ELC of
router B.
Best regards,
Xiaohu
*发件人:*George, Wes [mailto:[email protected]]
*发送时间:*2014年5月2日1:51
*收件人:*Xuxiaohu
*抄送:*[email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*主题:*Re: [sunset4] IPv6 router IDs
I got a bounce-back on all 3 draft aliases, trying again with the
authors’s email addresses directly.
*From: *<George>, "George, Wes"
<[email protected]
<mailto:[email protected]>>
*Date: *Thursday, May 1, 2014 at 1:42 PM
*To: *"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
*Subject: *[sunset4] IPv6 router IDs
I see that you have submitted two drafts for IPv6 router IDs in
ISIS
and OSPF, noting that the existing router ID is only 4 octets. This
has also come up in IDR for BGP. The authors of that draft are
copied. I’ll give you a similar set of feedback to what I
gave them -
It is important to distinguish between places where a unique
identifier is needed, and by *convention* an IPv4 address
assigned
to the device has been used to provide that unique ID, vs. places
where the actual IP address has some sort of importance to the
protocol (I.e. That information must be available to take action
on).
In other words, is the protocol requirement that the ID be
unique
across some domain, but that the actual value does not matter,
or is
the protocol requirement that the value must correspond to
something
on the router? In many of the former cases, the fact that the
value
isn’t relevant has been used to make recommendations that
are
easier
for humans to deal with (I.e. Tying the router ID to an IP
address)
but that value as a human-readable set of info does not
necessarily
justify changes to the protocol to support that convention as
we
move to IPv6.
I would argue that the router ID used in routing protocols must
merely be unique, but it doesn’t have to be an IP address at all.
Thus it is not strictly necessary to create a new field to carry
IPv6 addresses when operating without IPv4 addresses on a
network.
If you believe otherwise, the justification needs to be
documented
in the draft.
There are many places in IETF protocols where a 32 bit unique
identifier is needed, and by convention an IPv4 address has
been
used. It would be far more useful to write a general draft
identifying this problem and discussing several solutions,
including
simply generating unique IDs manually, systematically
generating a
random ID, etc. the place for such a draft may be in Sunset4,
either as a part of the existing gap analysis draft or as another
standalone draft.
There was rather a long discussion about this on IDR, thread
here:
https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr&q
=%
22
%5
Bidr%5D+%5Bv6ops%5D+BGP+Identifier%22&as=1&gbt=1
And in the IDR meeting, minutes:
http://www.ietf.org/proceedings/89/minutes/minutes-89-idr
(see page 11)
I’d encourage the authors of these drafts to work together on
this.
Thanks,
Wes George
Anything below this line has been added by my company’s
mail
server,
I have no control over it.
-----------
----------------------------------------------------------------
--
--
--
--
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.
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
