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

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

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.

   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-rfc49
> > > > > > 71
> > > > > > 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
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg