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:[email protected]] > Sent: Sunday, May 11, 2014 7:42 PM > To: Uma Chunduri; Acee Lindem > Cc: Wes George; Joel jaeggli; OSPF List; [email protected]; > [email protected] > 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; [email protected] <mailto:[email protected]>; Wes George; >> Anton Smirnov; >> [email protected] <mailto:[email protected]>; Joel jaeggli; > OSPF List; [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]> >> *Subject:* Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs >> >> Hi Uma, >> >> On May 9, 2014, at 8:03 PM, Uma Chunduri <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/isis-wg >> > > > > _______________________________________________ > sunset4 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sunset4 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
