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

Hi Les,

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
> 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:xuxiaohu@huawei.com]
> > 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:isis-wg-bounces@ietf.org] 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?

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

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > 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
> > > Isis-wg@ietf.org
> > > https://www.ietf.org/mailman/listinfo/isis-wg