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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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-addres
> > > > > > > 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. :-)

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-rfc49
> > > > > > > > 71
> > > > > > > > bi
> > > > > > > > s/
> > > > > > > > > > Htmlized:
> > > > > > > > https://tools.ietf.org/html/draft-ginsberg-isis-rfc4971bis
> > > > > > > > -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