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

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