Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

[Xuxiaohu <[e-mail]>]

Hi Les,

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> Sent: Friday, October 16, 2015 10:13 AM
> To: Xuxiaohu; ISIS-WG
> Cc: Stefano Previdi (sprevidi)
> Subject: RE: [Isis-wg] FW: New Version Notification for
> draft-ginsberg-isis-rfc4971bis-00.txt
> 
> Xiaohu -
> 
> > -----Original Message-----
> > From: Xuxiaohu [mailto:[e-mail]]
> > Sent: Thursday, October 15, 2015 12:43 AM
> > To: Les Ginsberg (ginsberg); ISIS-WG
> > Cc: Stefano Previdi (sprevidi)
> > Subject: RE: [Isis-wg] FW: New Version Notification for
> > draft-ginsberg-isis- rfc4971bis-00.txt
> >
> > Hi Les,
> >
> > > -----Original Message-----
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Thursday, October 15, 2015 12:32 PM
> > > To: Xuxiaohu; ISIS-WG
> > > Cc: Stefano Previdi (sprevidi)
> > > Subject: RE: [Isis-wg] FW: New Version Notification for
> > > draft-ginsberg-isis-rfc4971bis-00.txt
> > >
> > > Xiaohu -
> > >
> > > > -----Original Message-----
> > > > From: Xuxiaohu [mailto:[e-mail]]
> > > > Sent: Wednesday, October 14, 2015 6:38 PM
> > > > To: Les Ginsberg (ginsberg); ISIS-WG
> > > > Cc: Stefano Previdi (sprevidi)
> > > > Subject: RE: [Isis-wg] FW: New Version Notification for
> > > > draft-ginsberg-isis- rfc4971bis-00.txt
> > > >
> > > > Hi Les,
> > > >
> > > > > -----Original Message-----
> > > > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > > > Sent: Thursday, October 15, 2015 2:50 AM
> > > > > To: Xuxiaohu; ISIS-WG
> > > > > Cc: Stefano Previdi (sprevidi)
> > > > > Subject: RE: [Isis-wg] FW: New Version Notification for
> > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > >
> > > > > Xiaohu -
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Isis-wg [mailto:[e-mail]] On Behalf Of
> > > > > > Xuxiaohu
> > > > > > Sent: Monday, October 12, 2015 11:55 PM
> > > > > > To: Les Ginsberg (ginsberg); ISIS-WG
> > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > Subject: Re: [Isis-wg] FW: New Version Notification for
> > > > > > draft-ginsberg-isis- rfc4971bis-00.txt
> > > > > >
> > > > > > Hi Les,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > > > > > Sent: Tuesday, October 13, 2015 12:40 PM
> > > > > > > To: Xuxiaohu; ISIS-WG
> > > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > > Subject: RE: [Isis-wg] FW: New Version Notification for
> > > > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > > > >
> > > > > > > Xiaohu -
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Isis-wg [mailto:[e-mail]] On Behalf
> > > > > > > > Of Xuxiaohu
> > > > > > > > Sent: Monday, October 12, 2015 7:32 PM
> > > > > > > > To: Les Ginsberg (ginsberg); ISIS-WG
> > > > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > > > Subject: Re: [Isis-wg] FW: New Version Notification for
> > > > > > > > draft-ginsberg-isis- rfc4971bis-00.txt
> > > > > > > >
> > > > > > > > Hi Les,
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Les Ginsberg (ginsberg)
> > > > > > > > > [mailto:[e-mail]]
> > > > > > > > > Sent: Monday, October 12, 2015 8:39 PM
> > > > > > > > > To: Xuxiaohu; ISIS-WG
> > > > > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > > > > Subject: RE: [Isis-wg] FW: New Version Notification for
> > > > > > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > > > > > >
> > > > > > > > > Xiaohu -
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Xuxiaohu [mailto:[e-mail]]
> > > > > > > > > > Sent: Monday, October 12, 2015 1:27 AM
> > > > > > > > > > To: Les Ginsberg (ginsberg); ISIS-WG
> > > > > > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > > > > > Subject: RE: [Isis-wg] FW: New Version Notification
> > > > > > > > > > for
> > > > > > > > > > draft-ginsberg-isis- rfc4971bis-00.txt
> > > > > > > > > >
> > > > > > > > > > Hi Les,
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Isis-wg [mailto:[e-mail]] On
> > > > > > > > > > > Behalf Of Les Ginsberg
> > > > > > > > > > > (ginsberg)
> > > > > > > > > > > Sent: Thursday, October 08, 2015 12:04 PM
> > > > > > > > > > > To: ISIS-WG
> > > > > > > > > > > Cc: Stefano Previdi (sprevidi)
> > > > > > > > > > > Subject: [Isis-wg] FW: New Version Notification for
> > > > > > > > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > > > > > > > >
> > > > > > > > > > > Folks -
> > > > > > > > > > >
> > > > > > > > > > > We have just submitted a bis draft for RFC 4971 to
> > > > > > > > > > > define how to use TLV 242 on a router which supports
> > > > > > > > > > > only IPv6 (has no
> > > > > > > > > > > IPv4
> > > > > > > > addresses).
> > > > > > > > > > >
> > > > > > > > > > > The draft is identical to the original RFC except for:
> > > > > > > > > > >
> > > > > > > > > > > 1)New text at the beginning of Section 3 defining
> > > > > > > > > > > how to use the TLV when no
> > > > > > > > > > > IPv4 Router ID is present
> > > > > > > > > >
> > > > > > > > > > According to the definition of Router ID as defined in
> > > > > > > > > > RFC4971 as
> > > > > > follows:
> > > > > > > > > >
> > > > > > > > > > "A router that generates a CAPABILITY TLV MUST have a
> > > > > > > > > > Router ID
> > > > > > that
> > > > > > > > > >    is a 32-bit number.  The ID MUST be unique within
> > > > > > > > > > the IS-IS
> > > area.
> > > > > If
> > > > > > > > > >    the router generates any capability TLVs with
> > > > > > > > > > domain flooding
> > > > > > scope,
> > > > > > > > > >    then the ID MUST also be unique within the IS-IS
> > > > > > > > > > routing
> > > > domain."
> > > > > > > > > >
> > > > > > > > > > the router ID is just required to be a 32-bit number
> > > > > > > > > > which is unique within the area or the domain.
> > > > > > > > > >
> > > > > > > > > > However, it said in your draft,
> > > > > > > > > >
> > > > > > > > > > "...The Router ID SHOULD be identical to the value
> > > > > > > > > > advertised in
> > > > the
> > > > > > > > > >    Traffic Engineering Router ID TLV [RFC5305].  If no Traffic
> > > > > > > > > >    Engineering Router ID is assigned the Router ID
> > > > > > > > > > SHOULD be
> > > > > identical
> > > > > > > > > >    to an IP Interface Address [RFC1195] advertised by
> > > > > > > > > > the
> > > > originating
> > > > > > > > > >    IS. If the originating node does not support IPv4,
> > > > > > > > > > then the
> > > > reserved
> > > > > > > > > >    value 0.0.0.0 MUST be used in the Router ID field
> > > > > > > > > > and the IPv6
> > > TE
> > > > > > > > > >    Router ID sub-TLV [RFC5316] MUST be present in the
> TLV...."
> > > > > > > > > >
> > > > > > > > > > I'm wondering what's the reason for imposing the above
> > > > > > > > > > restriction on the router ID, especially in the case
> > > > > > > > > > where no TE is
> > > > > > enabled?
> > > > > > > > > > Or did you also want to know at least one routable IP
> > > > > > > > > > address of a given router that generates a Router
> > > > > > > > > > Capability TLV (see
> > > > > > > > > > https://tools.ietf.org/html/draft-xu-isis-routable-
> > > > > > > > > > ip-address-01)?
> > > > > > > > >
> > > > > > > > > [Les:] RFC 5305 and RFC 6119 which define the IPv4 and
> > > > > > > > > IPv6 Router ID TLVs respectively are explicit: the
> > > > > > > > > router ID MUST be a routable
> > > > > > address.
> > > > > > > > > It is conceivable that we could use a different ID in
> > > > > > > > > TLV
> > > > > > > > > 242
> > > > > > > > > - which is NOT required to be a routable address and is
> > > > > > > > > always
> > > > > > > > > 32 bits
> > > > > > > > > - but why would we want to do so? This places a burden
> > > > > > > > > on operators to assign yet another unique number to each
> > > > > > > > > node and then we need a way to correlate this number w
> > > > > > > > > the originating node
> > > > > > > > > - remembering that in the case of a leaked TLV 242 the
> > > > > > > > > originator is not contained in the TLV nor in
> > > > > > > > the containing LSP.
> > > > > > > >
> > > > > > > > In the case of a leaked TLV-242, the originator is
> > > > > > > > identified by the Router ID contained in the TLV. No?
> > > > > > > >
> > > > > > > [Les:] Yes - that is the intent - and nothing in the bis
> > > > > > > version changes that. All the bis version is clarifying is
> > > > > > > what value is used in the
> > > > > > fixed portion of TLV-242.
> > > > > > > Are you suggesting that the router-id field in the fixed
> > > > > > > portion of TLV 242 SHOULD be different than what is
> > > > > > > advertised in
> > TLV 134?
> > > > > > > If so, please explain why.
> > > > > > >
> > > > > > > > Of course, in the case where some routers in other areas
> > > > > > > > need to know a routable IP address of the originator of a
> > > > > > > > given leaked TLV-242, it needs to contain a particular
> > > > > > > > sub-TLV within that
> > > > > > > > TLV-242 so as to carry that routable IP address (e.g.,
> > > > > > > > https://tools.ietf.org/html/draft-xu-isis-routable-ip-addr
> > > > > > > > es
> > > > > > > > s- 01). That routable IP address could be identical to the
> > > > > > > > TE router ID if
> > > > > > assigned.
> > > > > > > > Furthermore, routers that do not support that specific
> > > > > > > > sub-TLV could continue processing those sub-TLVs that are
> > supported.
> > > > > > > >
> > > > > > > > In contrast, according the following rules as proposed in
> > > > > > > > your draft,
> > > > > > > >
> > > > > > > > "... If the originating node does not support IPv4, then
> > > > > > > > the
> > reserved
> > > > > > > >    value 0.0.0.0 MUST be used in the Router ID field and the IPv6
> TE
> > > > > > > >    Router ID sub-TLV [RFC5316] MUST be present in the TLV.
> > Router
> > > > > > > >    CAPABILITY TLVs which have a Router ID of 0.0.0.0 and
> > > > > > > > do NOT have
> > > > > the
> > > > > > > >    IPv6 TE Router ID sub-TLV present MUST be ignored...."
> > > > > > > >
> > > > > > > > It would cause backwards compatibility issues to those
> > > > > > > > RFC4971-compatible routers according to the following
> > specification:
> > > > > > > >
> > > > > > > > "...   A router that generates a CAPABILITY TLV MUST have a
> > Router
> > > ID
> > > > > > that
> > > > > > > >    is a 32-bit number.  The ID MUST be unique within the IS-IS
> area.
> > > If
> > > > > > > >    the router generates any capability TLVs with domain
> > > > > > > > flooding
> > > > scope,
> > > > > > > >    then the ID MUST also be unique within the IS-IS
> > > > > > > > routing
> > domain.
> > > > > > > > ..."
> > > > > > > >
> > > > > > > [Les:] For a router which does NOT support IPv4 - and
> > > > > > > therefore has no reachable IPv4 address assigned to any
> > > > > > > interface (including
> > > > > > > loopbacks)
> > > > > > > - please explain what value that router would put into the
> > > > > > > fixed portion of TLV 242 under the existing rules of RFC 4971?
> > > > > > > The router would NOT have an IPv4  TE Router ID (TLV 134) -
> > > > > > > nor would it have a reachable IPv4 address (TLV 132). So
> > > > > > > what value would be
> > > > used?
> > > > > > >
> > > > > > > Under existing rules the operator would have to invent such
> > > > > > > an address
> > > > > > > - and guarantee that it is unique - and do so on every node
> > > > > > > which needs to advertise TLV 242. This could be done - but
> > > > > > > is an unnecessary
> > > > > > burden for deployment.
> > > > > > > We are trying to make it easier to deploy an IPv6 only box
> > > > > > > by the bis changes so that a unique 32 bit router id does
> > > > > > > not have to be invented just so that a router can send TLV 242.
> > > > > > >
> > > > > > > As for backwards compatibility, the only way an IPv6 only
> > > > > > > router can send the Router Capability TLV under current RFC
> > > > > > > 4971 rules is to assign a unique 32 bit ID to the router.
> > > > > > > The bis version does not make this practice illegal, but it
> > > > > > > does introduce a stated preference for using TLV 134 value
> > > > > > > if available and
> > > > > > > 0.0.0.0 plus
> > > > > > > IPv6 Router ID sub-TLV if not avaialble. So folks who have
> > > > > > > IPv6 only deployments can continue to invent an IPv4 Router
> > > > > > > ID (as they MUST
> > > > > > > today) until they have fully deployed a version which
> > > > > > > supports the bis extensions. Then they can remove the IPv4
> > > > > > > Router ID and automatically enable the new
> > > > > > functionality.
> > > > > >
> > > > > > Does it mean the bis extension could not be deployed without a
> > > > > > flag
> > day?
> > > > > > imagine the scenario where an RFC4971-compatible router
> > > > > > receive two
> > > > > > TLV- 242s (with router id of 0.0.0.0) which are originated by
> > > > > > two IPv6-only
> > > > > routers.
> > > > > >
> > > > >
> > > > > [Les:] This was answered by my previous reply. Please read the
> > > > > paragraph immediately preceding your question.
> > > >
> > > > According to the following text from your previous reply
> > > >
> > > > "...So folks who have IPv6 only deployments can continue to invent
> > > > an
> > > > IPv4 Router ID (as they MUST today) until they have fully deployed
> > > > a version which supports the bis extensions..."
> > > >
> > > > Does it mean the routable IP address sub-TLV of the ISIS Router
> > > > Capability TLV is still necessary until " they have fully deployed
> > > > a version which supports the bis extensions"?
> > > >
> > >
> > > [Les:] If by " routable IP address sub-TLV of the ISIS Router
> > > Capability" you mean sub-TLV 11: IPv4 TE Router ID then read on.
> > > If not, then stop and explain which other sub-TLV you actually mean.
> >
> > It means the Routable IP Address sub-TLV as defined in
> > https://tools.ietf.org/html/draft-xu-isis-routable-ip-address
> >
> [Les:] The functionality defined in  draft-xu-isis-routable-ip-address has been
> provided by the sub-TLVs defined in
> http://datatracker.ietf.org/doc/draft-ietf-isis-prefix-attributes/ . This was agreed
> upon by all parties and you are a co-author. :-)

How to identify the source (i.e., a routable IP address) of TLV242 can be addressed by draft-xu-isis-routable-ip-address NO MATTER IPv4 is supported or not. More specifically, the source (i.e., a routable IP address) of TLV242 is identified by the Routable IP address sub-TLV of that TLV. There is no need to change the current usage of the 32-bit Router ID field of TLV242. That's to say, the 32-bit Router ID could be identical to the IPv4 TE router ID, an IPv4 interface address or just 32-bit integer as long as it's unique within the area or domain scope. Therefore, it would not cause any compatible issue as the bis extension does (e.g., an RFC4971-compatible router receive two TLV- 242s (with router id of 0.0.0.0) which are originated by two IPv6-only routers.). In addition, there is no need of enforcing the assignment of TE router ID even in the case where TE is not needed at all.

In contrast, draft-ietf-isis-prefix-attributes doesn't address the above issue very well (i.e., to identify the source of TLV242) due to the following reasons: The IPv4/IPv6 Source Router ID as defined in draft-ietf-isis-prefix-attributes MUST be identical to IPv4/IPv6Traffic Engineering router ID (TLV134/140). However, according to the current specification of TLV242 [RFC4971], there is no field to contain the IPv4/IPv6 TE router ID. As a result, it's impossible to correlate the routable IP addresses contained in IPv4/IPv6 reachability TLVs with TLV242. In other words, draft-ietf-isis-prefix-attributes ALONE could not address the above issue (i.e., to identify the source of TLV242.). Instead, it depends on the bis extension which enforces the containing of TE router ID within TLV242. However, as said before, it's a RFC4971-incompatible way to identify the source of TLV242. in contrast, draft-xu-isis-routable-ip-address describes a RFC4971-compatible way to identify the source of TLV-242. In a words, until all routers have been upgraded to support the bis extension, using the Routable IP Address sub-TLV as defined in draft-xu-isis-routable-ip-address is still a valid way to indicate the source of TLV242. Don't you think so?

Best regards,
Xiaohu

> This has nothing to do w rfc4971bis. The issue rfc4971bis is addressing is how to
> identify the source of TLV 142 when you don't have any IPv4 support.





>    Les
> 
> 
> > > There is no use for sub-TLV 11. There wasn't one before rfc4971bis
> > > draft and there isn't one after rfc4971bis draft. If we had all been
> > > smarter back when RFC
> > > 5316 was being written we would have realized that and never defined
> > > the sub-TLV.
> > >
> > > Sub-TLV 12: IPv6 TE Router ID is quite useful - and rfc4971bis is
> > > taking advantage of that.
> >
> > The value of the Routable IP Address sub-TLV as mentioned above could
> > be identical to TE Router ID if TE Router ID is assigned. If TE router
> > ID is not assigned, the value of the Routable IP Address could be
> > identical to an IP interface address advertised by that originator.
> > Meanwhile, there is no need to set the Router ID to 0.0.0.0. In other
> > words, operators could assign the router ID as what they have done
> > today. In this way, there is no compatible issue (e.g., an
> > RFC4971-compatible router receive two TLV- 242s (with router id of
> > 0.0.0.0) which are originated by two IPv6-only routers.). In addition,
> > there is no need of enforcing the assignment of TE router ID even in the case
> where TE is not needed at all.
> >
> > Best regards,
> > Xiaohu
> >
> > >    Les
> > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > > > >    Les
> > > > >
> > > > > > Best regards,
> > > > > > Xiaohu
> > > > > >
> > > > > > >    Les
> > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Xiaohu
> > > > > > > >
> > > > > > > > >    Les
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Xiaohu
> > > > > > > > > >
> > > > > > > > > > > 2)References have been updated
> > > > > > > > > > >
> > > > > > > > > > > Please let us know of any questions or comments.
> > > > > > > > > > >
> > > > > > > > > > >    Les (on behalf of Stefano and Mach)
> > > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: [e-mail]
> > > > > > > > > > > [mailto:[e-mail]]
> > > > > > > > > > > Sent: Wednesday, October 07, 2015 8:59 PM
> > > > > > > > > > > To: Mach Chen; Stefano Previdi (sprevidi); Les
> > > > > > > > > > > Ginsberg (ginsberg); Stefano Previdi (sprevidi); Les
> > > > > > > > > > > Ginsberg (ginsberg); Mach Chen
> > > > > > > > > > > (Guoyi)
> > > > > > > > > > > Subject: New Version Notification for
> > > > > > > > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > A new version of I-D,
> > > > > > > > > > > draft-ginsberg-isis-rfc4971bis-00.txt
> > > > > > > > > > > has been successfully submitted by Les Ginsberg and
> > > > > > > > > > > posted to the IETF repository.
> > > > > > > > > > >
> > > > > > > > > > > Name:		draft-ginsberg-isis-rfc4971bis
> > > > > > > > > > > Revision:	00
> > > > > > > > > > > Title:		IS-IS Extensions for Advertising Router Info
> > > > > > > > > > > Document date:	2015-10-07
> > > > > > > > > > > Group:		Individual Submission
> > > > > > > > > > > Pages:		9
> > > > > > > > > > > URL:
> > > > > > > > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-
> > > > > > > > > > > is
> > > > > > > > > > > is
> > > > > > > > > > > -r
> > > > > > > > > > > fc
> > > > > > > > > > > 49
> > > > > > > > > > > 71
> > > > > > > > > > > bi
> > > > > > > > > > > s-00.txt
> > > > > > > > > > > Status:
> > > > > > > > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc
> > > > > > > > > 49
> > > > > > > > > 71
> > > > > > > > > bi
> > > > > > > > > s/
> > > > > > > > > > > Htmlized:
> > > > > > > > > https://tools.ietf.org/html/draft-ginsberg-isis-rfc4971b
> > > > > > > > > is
> > > > > > > > > -0
> > > > > > > > > 0
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Abstract:
> > > > > > > > > > >    This document defines a new optional Intermediate
> > > > > > > > > > > System
> > > to
> > > > > > > > > > >    Intermediate System (IS-IS) TLV named CAPABILITY,
> > > > > > > > > > > formed of
> > > > > > > > multiple
> > > > > > > > > > >    sub-TLVs, which allows a router to announce its
> > > > > > > > > > > capabilities
> > > > > within
> > > > > > > > > > >    an IS-IS level or the entire routing domain.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Please note that it may take a couple of minutes
> > > > > > > > > > > from the time of submission until the htmlized
> > > > > > > > > > > version and diff are available at
> > > > > > > > tools.ietf.org.
> > > > > > > > > > >
> > > > > > > > > > > The IETF Secretariat
> > > > > > > > > > >
> > > > > > > > > > >
> > _______________________________________________
> > > > > > > > > > > Isis-wg mailing list [e-mail]
> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Isis-wg mailing list
> > > > > > > > [e-mail]
> > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg
> > > > > >
> > > > > > _______________________________________________
> > > > > > Isis-wg mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/isis-wg