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

[joel jaeggli <[e-mail]>]

On 5/11/14, 8:01 PM, Uma Chunduri wrote:
> 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.

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

an isis system id is neither 32 bits  nor ip.

> 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."

 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).
>  
>>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:[e-mail]]
> Sent: Sunday, May 11, 2014 7:42 PM
> To: Uma Chunduri; Acee Lindem
> Cc: Wes George; Joel jaeggli; OSPF List; [e-mail];
> [e-mail]
> Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
>  
> (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:
>> Hi Acee,
>>
>> My comments inline [Uma1]
>>
>> --
>>
>> Uma C.
>>
>> *From:*Acee Lindem
>> *Sent:* Friday, May 09, 2014 6:47 PM
>> *To:* Uma Chunduri
>> *Cc:* Xuxiaohu; [e-mail] <mailto:[e-mail]>; Wes George; Anton Smirnov;
>> [e-mail] <mailto:[e-mail]>; Joel jaeggli;
> OSPF List; [e-mail] <mailto:[e-mail]>;
>> [e-mail] <mailto:[e-mail]>
>> *Subject:* Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
>>
>> Hi Uma,
>>
>> On May 9, 2014, at 8:03 PM, Uma Chunduri <[e-mail] 
>> <mailto:[e-mail]>> 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
>>
>>>   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.
>>
>> [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
>> 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.
>>
>>
>>
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/isis-wg
>>
>  
> 
> 
> _______________________________________________
> sunset4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sunset4
>