Subject: Re: [OSPF] [Isis-wg] [sunset4] IPv6 router IDs

From: Acee Lindem <[email-masked]>
Date: Mon, 5 May 2014 14:28:01 +0000

Xiaohu – what are precisely the situations that you think you need this IPv6 address?
Acee

From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 4, 2014 1:29 AM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>
Cc: OSPF - OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]]
发送时间: 2014年5月2日 1:51
收件人: Xuxiaohu
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: 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-masked]<mailto:[email-masked]>>
Date: Thursday, May 1, 2014 at 1:42 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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%5Bidr%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.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 05 May 2014 10:54:49 -0500

> Xiaohu – what are precisely the situations that you think you need this

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.

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-masked] <mailto:[email-masked]>>
> Cc: OSPF - OSPF WG List <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
>     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-masked]]
>     *发送时间:*2014年5月2日1:51
>     *收件人:*Xuxiaohu
>     *抄送:[email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     *主题:*Re: [sunset4] IPv6 router IDs
> 
>      
> 
>     *From: *<George>, "George, Wes" <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Thursday, May 1, 2014 at 1:42 PM
>     *To: *"[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *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%5Bidr%5D+%5Bv6ops%5D+BGP+Identifier%22&as=1&gbt=1
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     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-masked]
> https://www.ietf.org/mailman/listinfo/sunset4
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 6 May 2014 01:48:00 +0000

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 joel jaeggli
> 发送时间: 2014年5月5日 23:55
> 收件人: Acee Lindem; Xuxiaohu; George, Wes
> 抄送: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 主题: Re: [Isis-wg] [sunset4] IPv6 router IDs
> 
> > Xiaohu – what are precisely the situations that you think you need
> > this
> > IPv6 address?
> > Acee
> 
> 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

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.

Best regards,
Xiaohu

> > <mailto:[email-masked]>" <[email-masked]
> > <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>"
> >     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
> >
> >
> >

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 May 2014 09:13:46 -0400

> 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 

> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 7 May 2014 01:10:07 +0000

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 for router A to know the ELC of router B.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Acee Lindem [mailto:[email-masked]]
> 发送时间: 2014年5月6日 21:14
> 收件人: Xuxiaohu
> 抄送: joel jaeggli; Acee Lindem; George, Wes; [email-masked]; OSPF List;
> [email-masked]; [email-masked]; [email-masked]
> 主题: Re: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
> 
> 
> >> 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
> > 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.
> 
> >> I don't find the embedding of semantic meaning in router-ids to be
> >> more compelling then it was in ip addresses.
> >>
> >>> --------------------------------------------------------------------
> >>> --
> >>> --
> >>>

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 08 May 2014 16:49:21 +0200

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 f
 o
r router A to know the ELC of router B.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 9 May 2014 00:53:26 +0000

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-masked]]
> 发送时间: 2014年5月8日 22:49
> 收件人: Xuxiaohu
> 抄送: [email-masked]; George, Wes; [email-masked]; joel jaeggli;
> OSPF List; [email-masked]; [email-masked]
> 主题: Re: [OSPF] 答复: 答复: [Isis-wg] [sunset4] IPv6 router IDs
> 
>     Hello Xiaohu,
> 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
> 
> 
> 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
> >> 抄送: joel jaeggli; Acee Lindem; George, Wes; [email-masked]; OSPF
> >> List; [email-masked]; [email-masked];
> >> [email-masked]
> >> "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
> >>>
> >>>>> https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr&q=%
> >>>>> 22
> >>>>> %5
> >>>>>     Anything below this line has been added by my company’s mail
> server,
> >>>>>     I have no control over it.
> >>>>>
> >>>>>     -----------
> >>>>>
> >>>>>
> >>>>>
> >>>>>

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 09 May 2014 10:57:54 +0200

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:
>> <mailto:[email-masked]>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 9 May 2014 09:31:04 +0000

Hi Karsten,

Your understanding is completely correct. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 Karsten Thomann
> 发送时间: 2014年5月9日 16:58
> 收件人: Xuxiaohu; Anton Smirnov
> 主题: 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
> 
> > 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
> 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
> >
> >> -----邮件原件-----
> >> 抄送: [email-masked]; George, Wes; [email-masked]; joel
> >> jaeggli; OSPF List; [email-masked]; [email-masked]
> >> 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
> >> 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
> >> 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
> >>>>>>> Xiaohu – what are precisely the situations that you think you
> >>>>>>> need this
> >>>>>>> IPv6 address?
> >>>>>>> Acee
> >>>>>> 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
> >>>> "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.
> >>>>>>
> >>>>>>>      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
> >>>>>>>      isn’t relevant has been used to make recommendations that
> >>>>>>> are
> >> easier
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> --
> >>>>>>> --
> >>>>>>>
> >>>>>>>      This E-mail and any of its attachments may contain Time
> >>>>>>> Warner
> >> Cable
> >>>>>>>      the sender immediately and permanently delete the original
> >>>>>>> and
> >> any
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 09 May 2014 11:49:30 +0200

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

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 9 May 2014 09:56:59 +0000

Hi Karsten,

The term "routable IP address " looks good to me. 

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: Karsten Thomann [mailto:[email-masked]]
> 发送时间: 2014年5月9日 17:50
> 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
> 
> >> 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
> >>
> >> 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
> >> 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
> >>>
> >>>> -----邮件原件-----
> >>>> 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
> >>>> own. As a result,
> >>>>>> 抄送: joel jaeggli; Acee Lindem; George, Wes; [email-masked];
> >>>>>> OSPF List; [email-masked]; [email-masked];
> >>>>>>>>> Cc: OSPF - OSPF WG List <[email-masked]
> >>>>>>>>> <mailto:[email-masked]>>, "[email-masked]
> >>>>>>>>> <mailto:[email-masked]>" <[email-masked]
> >>>>>>>>>       simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which
> >>>>>>>>> are used
> >> for
> >>>>>>>>>       it’s hard for routers in one area to establish
> >>>>>>>>> correlations
> >> between
> >>>>>>>>>       example, assume IS-IS router A in one area has
> >>>>>>>>> established a
> >> L3VPN
> >>>>>>>>>       a MPLS-SR tunnel, router A wants to know whether router
> >>>>>>>>> B has
> >>>> the
> >>>>>>>>>       ELC
> >>>>>>>>>       own. As a result, it’s hard for router A to know the ELC
> >>>>>>>>> of
> >> router B.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       Best regards,
> >>>>>>>>>
> >>>>>>>>>       Xiaohu
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       *发件人:*George, Wes
> >>>>>>>>>       I got a bounce-back on all 3 draft aliases, trying again with
> the
> >>>>>>>>>       authors’s email addresses directly.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       I see that you have submitted two drafts for IPv6 router
> >>>>>>>>> IDs in
> >> ISIS
> >>>>>>>>>       identifier is needed, and by *convention* an IPv4
> >>>>>>>>> address
> >> assigned
> >>>>>>>>>       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)
> >>>>>>>>>       justify  changes to the protocol to support that
> >>>>>>>>> convention as
> >> we
> >>>>>>>>>       move to IPv6.
> >>>>>>>>>
> >>>>>>>>>       IPv6 addresses when operating without IPv4 addresses on
> >>>>>>>>> a
> >>>> network.
> >>>>>>>>>       identifier is needed, and by convention an IPv4 address
> >>>>>>>>> has
> >> been
> >>>>>>>>>       identifying this problem and discussing several
> >>>>>>>>> solutions,
> >> including
> >>>>>>>>> https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr
> >>>>>>>>> &q
> >>>>>>>>> =%
> >>>>>>>>> 22
> >>>>>>>>> %5
> >>>>>>>>>       I’d encourage the authors of these drafts to work
> >>>>>>>>> together on
> >> this.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       Thanks,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       Wes George
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       subject to copyright belonging to Time Warner Cable.
> >>>>>>>>> This
> >> E-mail is
> >>>>>>>>>       the sender immediately and permanently delete the
> >>>>>>>>> original and
> >>>> any

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 May 2014 12:11:27 +0000

Xiaohu, 

The reason the use case is confusing is that the term L3VPN is commonly used to refer to RFC 4364 VPNs. In your use case, you are hypothesizing something for Segment Routed L3VPNs that I’m not sure is needed with MPLS. Can you add some real use cases to your drafts with justification that it is needed? 

Acee

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 May 2014 20:55:47 +0000

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-masked]] On Behalf Of Xuxiaohu
Sent: Friday, May 09, 2014 2:57 AM
To: Karsten Thomann; Anton Smirnov
Cc: [email-masked]; [email-masked]; George, Wes; joel jaeggli; OSPF List; [email-masked]; [email-masked]
Subject: [OSPF] 答复: [Isis-wg] 答复: 答复: [sunset4] IPv6 router IDs

Hi Karsten,

Best regards,
Xiaohu 

> I think that the question of the purpose of the drafts is clear now 
> and I hope George can confirm it.
> possible with an update to the rfc also for the IPv4 "Router ID" in the TLV...
> 
> >> 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
> >> 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 
> >> 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.
> >>>> 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
> >>>> IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for 
> >>>> however, only a 4-octect router ID is carried in them. As a 
> >>>> result, it’s hard for routers in one area to establish 
> >>>> 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
> >>>>>>>>> Xiaohu – what are precisely the situations that you think 
> >>>>>>>>> you need this
> >>>>>>>>> IPv6 address?
> >>>>>>>>> Acee
> >>>>>>>> I don't find the embedding of semantic meaning in router-ids 
> >>>>>>>> to be more compelling then it was in ip addresses.
> >>>>>>>>
> >>>>>>>>> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) 
> >>>>>>>>> is
> >> very
> >>>>>>>>>       however, only a 4-octect router ID is carried in them. 
> >>>>>>>>> As a
> result,
> >>>>>>>>>       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
> >>>>>>>>>       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
> >>>>>>>>>       I see that you have submitted two drafts for IPv6 
> >>>>>>>>> router IDs in
> >> ISIS
> >>>>>>>>>       has also come up in IDR for BGP. The authors of that 
> >>>>>>>>> draft
> are
> >>>>>>>>>       where the actual IP address has some sort of 
> >>>>>>>>> importance to
> the
> >>>>>>>>>       In other words, is the protocol requirement that the 
> >>>>>>>>> ID be
> >> unique
> >>>>>>>>>       the protocol requirement that the value must 
> >>>>>>>>> correspond to
> >>>> something
> >>>>>>>>>       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
> >>>>>>>>>       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.
> >>>>>>>>>       IPv6 addresses when operating without IPv4 addresses 
> >>>>>>>>> on a
> >>>> network.
> >>>>>>>>>       If you believe otherwise, the justification needs to 
> >>>>>>>>> be
> >> documented
> >>>>>>>>>       in the draft.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       identifier is needed, and by convention an IPv4 
> >>>>>>>>> address has
> >> been
> >>>>>>>>>       either as a part of the existing gap analysis draft or 
> >>>>>>>>> as
> another
> >>>>>>>>>       standalone draft.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>>       This E-mail and any of its attachments may contain 
> >>>>>>>>> Time Warner
> >>>> Cable
> >>>>>>>>>       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,
> >>>>>>>>>       unlawful. If you have received this E-mail in error, 
> >>>>>>>>> please
> notify

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 May 2014 21:00:06 +0000

Hi Acee,

You asked a good question.

Time and again it's required to identify the node to  establish dynamic connection, without having to worry if the route is hosted by 
the node or not (same properties as of  IS-IS TLV 134 and TLV 140, i.e., routable IP addresses, except not specific to TE)

I can see these -
1.  RLFA TLDP session without having to worry a PQ node supports TE or not
2. Orchestration software on a controller or an application which is having access to 
   the topology database of the network may determine the node IP address without having to go through the hoops (to determine if it's redistributed or leaked etc..)
   with this TLV.

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Friday, May 09, 2014 5:11 AM
To: Xuxiaohu
Cc: [email-masked]; Wes George; Anton Smirnov; [email-masked]; Joel jaeggli; OSPF List; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs

Xiaohu, 

Acee
On May 9, 2014, at 5:31 AM, Xuxiaohu <[email-masked]> wrote:

>> However, in the IPv6 network, there is no counterpart field to contain a routable IPv6 address.
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
>>>> -----邮件原件-----
>>>>>>>>>     simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which are 
>>>>>>>>> used
>> for
>>>>>>>>>     example, assume IS-IS router A in one area has established 
>>>>>>>>> a
>> L3VPN
>>>>>>>>>     protocol (I.e. That information must be available to take 
>>>>>>>>> action
>> on).
>>>>>>>>> 
>>>>>>>>>     on the router? In many of the former cases, the fact that 
>>>>>>>>> the
>> value
>>>>>>>>>     I’d encourage the authors of these drafts to work together 
>>>>>>>>> on
>> this.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>     Thanks,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>     Wes George
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 May 2014 22:11:22 +0000

Hi Uma, 

See inline. 

-----Original Message-----
From: Uma Chunduri <[email-masked]>
Date: Friday, May 9, 2014 2:00 PM
To: Ericsson <[email-masked]>, Xuxiaohu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Wes George
<[email-masked]>, Anton Smirnov <[email-masked]>,
"[email-masked]" <[email-masked]>, Joel jaeggli
<[email-masked]>, OSPF - OSPF WG List <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [Isis-wg] [OSPF] 答复:  答复:  [sunset4]   IPv6 router IDs

>Time and again it's required to identify the node to  establish dynamic
>connection, without having to worry if the route is hosted by
>the node or not (same properties as of  IS-IS TLV 134 and TLV 140, i.e.,
>routable IP addresses, except not specific to TE)
>
>I can see these -

I don't think this is a good use case. You need to have an the AF topology
in order to compute the remote LFA. Also, you may inherit remote LFA
targets for external and prefixes from other areas but you will never
compute remote LFA targets in other areas (at least not with today's
algorithms). 

>   the topology database of the network may determine the node IP address
>without having to go through the hoops (to determine if it's
>redistributed or leaked etc..)
>   with this TLV.

Can you be more precise? If the orchestration application is going to
orchestrate across multiple areas, I would hope it would have visibility
to the topologies of these areas.

Thanks,
Acee 

>Cc: [email-masked]; Wes George; Anton Smirnov; [email-masked];
>Joel jaeggli; OSPF List; [email-masked]; [email-masked]
>The reason the use case is confusing is that the term L3VPN is commonly
>used to refer to RFC 4364 VPNs. In your use case, you are hypothesizing
>something for Segment Routed L3VPNs that I’m not sure is needed with
>MPLS. Can you add some real use cases to your drafts with justification
>that it is needed?
>
>Acee
>>>>>>>>>>     I got a bounce-back on all 3 draft aliases, trying again
>>>>>>>>>>with the

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 10 May 2014 00:03:54 +0000

Hi Acee,

>1.  RLFA TLDP session without having to worry a PQ node supports TE or

I don't think this is a good use case. You need to have an the AF topology in order to compute the remote LFA. Also, you may inherit remote LFA targets for external and prefixes from other areas but you will never compute remote LFA targets in other areas (at least not with today's algorithms).

[Uma]: It doesn't have to be a different area. Take a simplest case of one area or an L2 domain; after having computed all the PQ nodes in that area/domain if the PQ node doesn't support TE and doesn't advertise router ID (TLV 134) which IP address you would pick for TLDP session ?  You can't reliably know from the advertised prefixes from the node that it is hosted by  the node if router ID is not emitted by the node (as it doesn't support TE).

>   the topology database of the network may determine the node IP
>address without having to go through the hoops (to determine if it's

Can you be more precise? If the orchestration application is going to orchestrate across multiple areas, I would hope it would have visibility to the topologies of these areas.

[Uma]: Even for a same area or domain having a node advertise it's loopback as router ID  without relation any relation to TE (supported or not) is a benefit in this case.
The ability of  an application on a controller to know this easily is a huge advantage.
Also there could be multiple loopback and each for different purposes. For e.g. a PCE on a controller with  https://tools.ietf.org/html/draft-ietf-pce-pceps can know PCC address
with a firewall port/IP opened on the router for TLS connection.  It would be great this can happen easily and automatically.

--
Uma C.

---

From: Acee Lindem <[email-masked]>
Date: Sat, 10 May 2014 01:46:53 +0000

Hi Uma,

On May 9, 2014, at 8:03 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee,

The only advantage I can see is that a router can explicitly specify which local address it wants to use for targeted LFA sessions.

I don’t think anyone would have a firewall within an IGP routing domain. Hence, it would be the same purported advantage as above.

Thanks,
Acee

--
Uma C.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 12 May 2014 01:44:13 +0000

Hi Acee,

IMHO, segment routing could work together with the RFC3464 VPN. In such case, the segment routing just replace the role of LDP or RSVP-TE of establishing a transport LSP between PE routers.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Acee Lindem [mailto:[email-masked]]
> 发送时间: 2014年5月9日 20:11
> 收件人: Xuxiaohu
> 抄送: Karsten Thomann; Anton Smirnov; [email-masked];
> [email-masked]; Wes George; Joel jaeggli; OSPF List;
> The reason the use case is confusing is that the term L3VPN is commonly used to
> refer to RFC 4364 VPNs. In your use case, you are hypothesizing something for
> Segment Routed L3VPNs that I’m not sure is needed with MPLS. Can you add
> some real use cases to your drafts with justification that it is needed?
> 
> Acee

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 12 May 2014 02:29:59 +0000

Hi Acee,

My comments inline [Uma1]

--
Uma C.

From: Acee Lindem
Sent: Friday, May 09, 2014 6:47 PM
To: Uma Chunduri
Cc: Xuxiaohu; [email-masked]; Wes George; Anton Smirnov; [email-masked]; Joel jaeggli; OSPF List; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs

Hi Uma,

Hi Acee,

[Uma1]: Yes Acee. This is more practical way and a separate IP can be hosted for this and this has to be advertised as “router IP”

[Uma]: IMO, it depends on the controller (where it’s located) and how many areas/ASes it is overseeing and also depends on applications it’s giving to access to network nodes.
             In a pure IGP environment, application of FW may not be necessary, but  giving access to the nodes through applications/controller is completely a different thing and security requirements can be different.
            Also the main point as you can see here is not only about security but it’s about giving visibility of the “router IP” through topology database to an outside entity.

Overall , FWIW it’s an useful addition to indicate this through (a sub-tlv of) the router capability TLV as presented here.

--
Uma  C.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 May 2014 22:41:45 -0400

(Only to Acee and Uma.  I will let you two sort this out on the list.)

Reading this thread, it look's to me like whatever uses this has, they 
are not related to the router ID.
So if there is anything here at all, it is some other service address 
advertisement.

Uma, I would point out that currently one can not assume that a received 
router ID is a usqble address.  Hence, there has to be an upgrade to the 
advertising router to indicate this new usage.  If there is an upgrade, 
then most of the use cases are addressed either by upgrading to the 
feature you really want, or by some form of service address 
advertisement.  Router ID does not seem to be the right hook.

Yours,
Joel

On 5/11/14, 10:29 PM, Uma Chunduri wrote:
> *From:*Acee Lindem
> *Sent:* Friday, May 09, 2014 6:47 PM
> *To:* Uma Chunduri
> *Cc:* Xuxiaohu; [email-masked]; Wes George; Anton Smirnov;
> [email-masked]; Joel jaeggli; OSPF List; [email-masked];
> *Subject:* Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
>
> Hi Uma,
>
> On May 9, 2014, at 8:03 PM, Uma Chunduri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
> Hi Acee,
>
> In-line [Uma]:
>
>>I can see these -
>
>>1.  RLFA TLDP session without having to worry a PQ node supports TE or
>
>>not
>
> I don't think this is a good use case. You need to have an the AF
> topology in order to compute the remote LFA. Also, you may inherit
> remote LFA targets for external and prefixes from other areas but you
> will never compute remote LFA targets in other areas (at least not with
> today's algorithms).
>
> [Uma]: It doesn't have to be a different area. Take a simplest case of
> one area or an L2 domain; after having computed all the PQ nodes in that
> area/domain if the PQ node doesn't support TE and doesn't advertise
> router ID (TLV 134) which IP address you would pick for TLDP session ?
> You can't reliably know from the advertised prefixes from the node that
> it is hosted by  the node if router ID is not emitted by the node (as it
> doesn't support TE).
>
> The only advantage I can see is that a router can explicitly specify
> which local address it wants to use for targeted LFA sessions.
>
>
> [Uma1]: Yes Acee. This is more practical way and a separate IP can be
> hosted for this and this has to be advertised as “router IP”
>
>>2. Orchestration software on a controller or an application which is
>
>>having access to
>
> [Uma]: Even for a same area or domain having a node advertise it's
> loopback as router ID without relation any relation to TE (supported or
> not) is a benefit in this case.
>
> Also there could be multiple loopback and each for different purposes.
> For e.g. a PCE on a controller
> withhttps://tools.ietf.org/html/draft-ietf-pce-pcepscan know PCC address
>
> with a firewall port/IP opened on the router for TLS connection. It
> would be great this can happen easily and automatically.
>
> I don’t think anyone would have a firewall within an IGP routing domain.
> Hence, it would be the same purported advantage as above.
>
> [Uma]: IMO, it depends on the controller (where it’s located) and how
> many areas/ASes it is overseeing and also depends on applications it’s
> giving to access to network nodes.
>
>               In a pure IGP environment, application of FW may not be
> necessary, but  giving access to the nodes through
> applications/controller is completely a different thing and security
> requirements can be different.
>
>              Also the main point as you can see here is not only about
> security but it’s about giving visibility of the “router IP” through
> topology database to an outside entity.
>
> Overall , FWIW it’s an useful addition to indicate this through (a
> sub-tlv of) the router capability TLV as presented here.
>
> --
>
> Uma  C.
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 12 May 2014 03:01:23 +0000

Dear Joel,

>Uma, I would point out that currently one cannot assume that a received router ID is a usqble address.

I agree this is true for OSPF.

But for IS-IS it's always a routable IP, but the point is it may not be there if there is no TE.

RFC 6119
        " 4.1.  IPv6 TE Router ID TLV

        The IPv6 TE Router ID TLV is TLV type 140.

         The IPv6 TE Router ID TLV contains a 16-octet IPv6 address.  A stable
        global IPv6 address MUST be used, so that the router ID provides a
        routable address, regardless of the state of a node's interfaces.

         If a router does not implement traffic engineering, it MAY include or
         omit the IPv6 TE Router ID TLV."

Same story for IPv4 per RFC 5305. It's better to leave this "Router ID"  alone for this purpose (or relax this to non TE purposes too, but one can't advertise multiple of them).

>Hence, there has to be an upgrade to the advertising router to indicate this new usage.  If there is an upgrade, then most of the use cases are addressed either by upgrading to the feature you really want, or by some form of service address >advertisement.  Router ID does not seem to be the right hook.

Instead of "Router ID", I agree it's better to call it as Service IP or "routable IP address" TLV.
Yes, upgrade would be require for any node to emit this one!

--
Uma C.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Sunday, May 11, 2014 7:42 PM
To: Uma Chunduri; Acee Lindem
Cc: Wes George; Joel jaeggli; OSPF List; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs

Reading this thread, it look's to me like whatever uses this has, they are not related to the router ID.
So if there is anything here at all, it is some other service address advertisement.

Uma, I would point out that currently one can not assume that a received router ID is a usqble address.  Hence, there has to be an upgrade to the advertising router to indicate this new usage.  If there is an upgrade, then most of the use cases are addressed either by upgrading to the feature you really want, or by some form of service address advertisement.  Router ID does not seem to be the right hook.

Yours,
Joel

On 5/11/14, 10:29 PM, Uma Chunduri wrote:
> *Cc:* Xuxiaohu; [email-masked]<mailto:[email-masked]>; Wes George; Anton Smirnov;
> [email-masked]<mailto:[email-masked]>; Joel jaeggli; OSPF List; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> will never compute remote LFA targets in other areas (at least not
> with today's algorithms).
>
> one area or an L2 domain; after having computed all the PQ nodes in
> that area/domain if the PQ node doesn't support TE and doesn't
> advertise router ID (TLV 134) which IP address you would pick for TLDP session ?
> You can't reliably know from the advertised prefixes from the node
> that it is hosted by  the node if router ID is not emitted by the node
> (as it doesn't support TE).
>
> orchestrate across multiple areas, I would hope it would have
> visibility to the topologies of these areas.
>
> [email-masked]<mailto:[email-masked]>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 11 May 2014 21:25:16 -0700

> But for IS-IS it's always a routable IP, but the point is it may not be

an sub tlv 6 interface-id is a not router-id

an isis system id is neither 32 bits  nor ip.

>          omit the IPv6 TE Router ID TLV."

 IPv6 TE Router ID TLV

is not semantically equivalent to router-id or system  id and should not
be treated as  such.

> Same story for IPv4 per RFC 5305. It's better to leave this "Router ID"
> alone for this purpose (or relax this to non TE purposes too, but one
> can't advertise multiple of them).
>  
>> *Cc:* Xuxiaohu; [email-masked] <mailto:[email-masked]>; Wes George; Anton Smirnov;
>> [email-masked] <mailto:[email-masked]>; Joel jaeggli;
> OSPF List; [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>