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

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-rfc4971
> > > > > bi
> > > > > s-00.txt
> > > > > Status:
> > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc4971bis/
> > > > > 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