Few comments:
1. Yes, router ID could be just a number in some protocols and it's a routable
IP address in some protocols but conditionally optional (IS-IS). In that sense
it's good to if we don't use that term.
2. This topic comes again and again but without association to TE it's good to
have a TLV/SUB-TLV defined which represents a routable IP address of a router.
Few months back while discussing RLFA
I proposed this
http://www.ietf.org/mail-archive/web/rtgwg/current/msg04316.html (towards the
end of the message).
3. Other option is as suggested by Les just relax it non-TE too and re-use the
existing TLVs (5305 and 6119) for this purpose; as though these are Router
ID's, these are routable.
--
Uma C.
-----Original Message-----
From: OSPF [mailto:[email protected]] On Behalf Of Xuxiaohu
Sent: Friday, May 09, 2014 2:57 AM
To: Karsten Thomann; Anton Smirnov
Cc: [email protected]; [email protected]; George, Wes; joel jaeggli; OSPF
List; [email protected]; [email protected]
Subject: [OSPF] 答复: [Isis-wg] 答复: 答复: [sunset4] IPv6 router IDs
Hi Karsten,
The term "routable IP address " looks good to me.
Best regards,
Xiaohu
> -----邮件原件-----
> 发件人: Karsten Thomann [mailto:[email protected]]
> 发送时间: 2014年5月9日 17:50
> 收件人: 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 Xuxiaohu,
>
> I think that the question of the purpose of the drafts is clear now
> and I hope George can confirm it.
> The problem I would like to get addressed is the term Router ID in the
> drafts, as the Router ID is not necessarily a routable address, if
> possible with an update to the rfc also for the IPv4 "Router ID" in the TLV...
>
> Or do you (or someone else) have any objections or problems with a
> change of the term to clarify that it is not the router ID?
>
> Kind regards
>
> Am 09.05.2014 11:31, schrieb Xuxiaohu:
> > Hi Karsten,
> >
> > Your understanding is completely correct.
> >
> > Best regards,
> > Xiaohu
> >
> >> -----邮件原件-----
> >> 发件人: 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=i
> >>>>>>>>> dr
> >>>>>>>>> &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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
