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: 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-address-
> > > > > 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.

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.

   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-isis-r
> > > > > > > > fc
> > > > > > > > 49
> > > > > > > > 71
> > > > > > > > bi
> > > > > > > > s-00.txt
> > > > > > > > Status:
> > > > > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc4971bi
> > > > > > s/
> > > > > > > > Htmlized:
> > > > > > https://tools.ietf.org/html/draft-ginsberg-isis-rfc4971bis-00
> > > > > > > >
> > > > > > > >
> > > > > > > > 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