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

   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-rfc4971bi
> > > > 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