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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Oct 2015 04:04:04 +0000

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

2)References have been updated 

Please let us know of any questions or comments.

   Les (on behalf of Stefano and Mach)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Oct 2015 21:43:38 -0700

two observations off the cuff:
a)

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

OK, so won't we end up with different understanding of what a router
ID is between routers supporting this CAP sub-TLV and routers that
don't in case the router ID in the new sub-TLV and the normal (5305)
do not agree  unless you specify that 5305 takes preference _or_ say
that they MUST (and not SHOULD) match ?

Interesting conversation as to what today's routers do if you give
them 0.0.0.0 for IPv4 TE ID.

b) " In order for Router CAPABILITY TLVs with domain-wide scope originated

   by L1 Routers to be flooded across the entire domain, at least one
   L1/L2 Router in every area of the domain MUST support the Router
   CAPABILITY TLV."

that seems to indicate that a router CAN originate a domain-wide scope
even though it doesn't a L1/L2 in the domain supporting the CAP TLV
but it can be read as "though SHALL NOT".

Side question: what is the indication that a router supports CAP TLV ?
Does it have to advertise an empty one even if it has nothing to tell
to indicate that "I support CAP TLV"

just perfunctory read between other stuff ...

thanks

-- tony

On Wed, Oct 7, 2015 at 9:04 PM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> 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).
>
> To: Mach Chen; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg);
> Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Mach Chen (Guoyi)
> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Oct 2015 21:45:26 -0700

though it does not _see_ a L1/L2 ...  sorry for omission ...

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Oct 2015 22:29:04 -0700

I had a strong 'deja-vu' that was bothering me and realized after reading
announcement carefully it's just update on RFC4971 and not a new router CAP
;-)  so my b) comment is kind of couple years behind ;-) but still valid
...

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Oct 2015 05:38:51 +0000

Tony –

Thjanx for the quick comments.

From: Tony Przygienda [mailto:[email-masked]]
Sent: Wednesday, October 07, 2015 9:44 PM
To: Les Ginsberg (ginsberg)
Cc: ISIS-WG; Stefano Previdi (sprevidi)
Subject: Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

OK, so won't we end up with different understanding of what a router ID is between routers supporting this CAP sub-TLV and routers that don't in case the router ID in the new sub-TLV and the normal (5305) do not agree  unless you specify that 5305 takes preference _or_ say that they MUST (and not SHOULD) match ?

Interesting conversation as to what today's routers do if you give them 0.0.0.0 for IPv4 TE ID.

[Les:] The reason SHOULD is used is because a strict interpretation of the existing RFC allows the router ID to be different than TLV 134 (RFC 5305) simply because the RFC does not say that they MUST be the same – in fact it doesn’t say anything at all about the relationship. I don’t know why any implementation would use something other than what they advertise in TLV 134 (assuming it is advertised) – but it did not seem to make sense to have the bis version suddenly make existing implementations non-conformant. I would hope all implementations are already doing this, but who knows…?

   CAPABILITY TLV."

that seems to indicate that a router CAN originate a domain-wide scope even though it doesn't a L1/L2 in the domain supporting the CAP TLV but it can be read as "though SHALL NOT".

[Les:] An L1 router can generate a Router Capability TLV with domain-wide scope – but clearly unless there exists an L2 router in the area the domain-wide flooding will never occur. That’s the point the existing text is trying to make (just in case you didn’t already know that. ☺ )

Side question: what is the indication that a router supports CAP TLV ? Does it have to advertise an empty one even if it has nothing to tell to indicate that "I support CAP TLV"

[Les:] There is no indication of support – and no need to generate a CAP TLV unless you actually have something to advertise.

Why do you think such a thing would be needed?

   Les

thanks

-- tony

On Wed, Oct 7, 2015 at 9:04 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Folks -

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 7 Oct 2015 23:10:13 -0700

>
>
>
>
> *From:* Tony Przygienda [mailto:[email-masked]]
> *Sent:* Wednesday, October 07, 2015 9:44 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* ISIS-WG; Stefano Previdi (sprevidi)
> *Subject:* Re: [Isis-wg] FW: New Version Notification for
> draft-ginsberg-isis-rfc4971bis-00.txt
>
>
>
> *[Les:] The reason SHOULD is used is because a strict interpretation of the existing RFC allows the router ID to be different than TLV 134 (RFC 5305) simply because the RFC does not say that they MUST be the same – in fact it doesn’t say anything at all about the relationship. I don’t know why any implementation would use something other than what they advertise in TLV 134 (assuming it is advertised) – but it did not seem to make sense to have the bis version suddenly make existing implementations non-conformant. I would hope all implementations are already doing this, but who knows…?*
>
> OK, hmm, so we leave a hole because we have a hole is not an impressive
reasoning but since no'one bumped over the hole it seems it's small ;-)
 About as much I have to say about it.

> *[Les:] An L1 router can generate a Router Capability TLV with domain-wide scope – but clearly unless there exists an L2 router in the area the domain-wide flooding will never occur. That’s the point the existing text is trying to make (just in case you didn’t already know that. **J** )*
>
>
>
> *[Les:] There is no indication of support – and no need to generate a CAP TLV unless you actually have something to advertise.*
>
> *Why do you think such a thing would be needed? *
>
>
>
> Would be only needed if such a "SHALL NOT" would be in place, i.e. someone
can advertise certain capability only if other routers have it but since I
agree the most natural interpretation of the text is "you can do it, it
just won't flood domain-wide", no need I see.

Like I said, I had the deja vu while writing my comments [which were minor
anyway], had to re-read to remember the details (I'm soaking in many more
than a single protocol or layer or technology these days, my brain starts
as self-defense swap things out quickly ;-) , I agree that no further
action is needed.

thanks for amusing me ;-)

-- tony

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 8 Oct 2015 18:42:54 +0000

In various contexts this hole has been discussed multiple times and today we have to have an IPv4 router ID have to be configured even for IPv6-only deployments.
I see the proposed text is a reasonable and perhaps less disruptive way to address this . 

May be it's good disambiguate further this should be tied to TLV 140 (RFC 6119); meaning the  sub-TLV 12 (RFC 5316) should be matching to TLV 140 if both are present.
Thoughts?
--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, October 07, 2015 9:04 PM
To: ISIS-WG
Cc: Stefano Previdi (sprevidi)
Subject: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

Folks -

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

Abstract:

The IETF Secretariat

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Oct 2015 18:50:41 +0000

Uma -

Thanx for the comments.

If you read RFC 5316 Section 3.2 I think it is clear that the TLV 242 sub-TLVs defined there are meant to advertise what is in TLVs 134/140.

If you think that RFC 5316 is not explicit enough we can discuss the best way to clarify that. I am not sure that rfc4971bis is the best place to do that - but we can certainly discuss.

   Les

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 11:43 AM
> To: Les Ginsberg (ginsberg); ISIS-WG
> Subject: RE: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-
> rfc4971bis-00.txt
> 
> 
> In various contexts this hole has been discussed multiple times and today we
> have to have an IPv4 router ID have to be configured even for IPv6-only
> deployments.
> May be it's good disambiguate further this should be tied to TLV 140 (RFC
> 6119); meaning the  sub-TLV 12 (RFC 5316) should be matching to TLV 140 if
> both are present.
> Thoughts?
> --
> Uma C.
> 
> 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).
> 
> To: Mach Chen; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Stefano
> Previdi (sprevidi); Les Ginsberg (ginsberg); Mach Chen (Guoyi)
> 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
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 8 Oct 2015 23:03:58 +0000

Les,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, October 08, 2015 11:51 AM
To: Uma Chunduri; ISIS-WG
Cc: Stefano Previdi (sprevidi)
Subject: RE: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

Uma -

Thanx for the comments.

If you read RFC 5316 Section 3.2 I think it is clear that the TLV 242 sub-TLVs defined there are meant to advertise what is in TLVs 134/140.
[Uma]:  Loosely yes, but it really gets murky  if we see 3.3.4 and 3.3.5.

[Uma]:  It's not that explicit, IMO. I am sure you are thinking of the implications from 5316 PoV if we make it explicit? 
Like v4, it's too good to clarify non-TE situation with IPv6 too. 

   Les

> Subject: RE: [Isis-wg] FW: New Version Notification for 
> draft-ginsberg-isis- rfc4971bis-00.txt
> 
> 
> In various contexts this hole has been discussed multiple times and 
> today we have to have an IPv4 router ID have to be configured even for 
> IPv6-only deployments.
> May be it's good disambiguate further this should be tied to TLV 140 
> (RFC 6119); meaning the  sub-TLV 12 (RFC 5316) should be matching to 
> TLV 140 if both are present.
> Thoughts?
> --
> Uma C.
> 
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Les 
> Ginsberg
> (ginsberg)
> 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).
> 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Oct 2015 23:37:07 +0000

(Not sure why Mach's email address keeps disappearing from the TO list - hopefully he is receiving copies via the WG alias)

Uma -

Mach and I have had some discussions about doing a BIS for RFC 5316 because TLV 141 has a similar issue since its format stipulates a 32 bit router ID. If that were to happen I think that is the best place to clarify the content of sub-TLVs 11/12.
What do you think?

Note  that we don't really have a use case for sub-TLV 11(IPv4 Router ID) since that Router ID can be encoded in the fixed part of TLV 141/242.

Note also that to resolve the TLV 141 issue we need to define the equivalent of TLV242/sub-TLV 12 for TLV 141.

   Les

> Sent: Thursday, October 08, 2015 4:04 PM
> If you read RFC 5316 Section 3.2 I think it is clear that the TLV 242 sub-TLVs
> defined there are meant to advertise what is in TLVs 134/140.
> If you think that RFC 5316 is not explicit enough we can discuss the best way
> to clarify that. I am not sure that rfc4971bis is the best place to do that - but
> we can certainly discuss.
> 
> [Uma]:  It's not that explicit, IMO. I am sure you are thinking of the
> implications from 5316 PoV if we make it explicit?

---

From: Mach Chen <[email-masked]>
Date: Fri, 9 Oct 2015 02:05:38 +0000

Hi Les,

Thanks for the clear explanation! 

> Sent: Friday, October 09, 2015 7:37 AM
> Cc: Stefano Previdi (sprevidi); Mach Chen
> (Not sure why Mach's email address keeps disappearing from the TO list -
> hopefully he is receiving copies via the WG alias)

Yes, I am watching :-)

> 
> Uma -
> 
> Mach and I have had some discussions about doing a BIS for RFC 5316 because
> TLV 141 has a similar issue since its format stipulates a 32 bit router ID. If that
> were to happen I think that is the best place to clarify the content of sub-TLVs
> 11/12.
> What do you think?
> 
> Note  that we don't really have a use case for sub-TLV 11(IPv4 Router ID) since
> that Router ID can be encoded in the fixed part of TLV 141/242.

Regarding sub-TLV 11, when sent with the 32 bit router ID, it is indeed a bit redundant. 
Thinking more about it, there may be a use case that two IPv4 networks(ASes) connected by a IPv6 network (AS), for the IPv6 AS, the ASBRs support dual stack. To setup an end-to-end IPv4 TE LSP, the ASBRs to need to advertise their IPv4 TE Router ID within the domain. Is this case valid?

Best regards,
Mach

> > If you read RFC 5316 Section 3.2 I think it is clear that the TLV 242
> > sub-TLVs defined there are meant to advertise what is in TLVs 134/140.
> > If you think that RFC 5316 is not explicit enough we can discuss the
> > best way to clarify that. I am not sure that rfc4971bis is the best
> > place to do that - but we can certainly discuss.
> >
> > > today we have to have an IPv4 router ID have to be configured even
> > > for IPv6-only deployments.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Oct 2015 02:14:47 +0000

Mach -

Good to know you are there. :-)

> From: Mach Chen [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 7:06 PM
> To: Les Ginsberg (ginsberg); Uma Chunduri; ISIS-WG
> > (Not sure why Mach's email address keeps disappearing from the TO list
> > - hopefully he is receiving copies via the WG alias)
> 
> Yes, I am watching :-)
> 
> >
> > Uma -
> >
> > Mach and I have had some discussions about doing a BIS for RFC 5316
> > because TLV 141 has a similar issue since its format stipulates a 32
> > bit router ID. If that were to happen I think that is the best place
> > to clarify the content of sub-TLVs 11/12.
> > What do you think?
> >
> > Note  that we don't really have a use case for sub-TLV 11(IPv4 Router
> > ID) since that Router ID can be encoded in the fixed part of TLV 141/242.
> 
> Thinking more about it, there may be a use case that two IPv4
> networks(ASes) connected by a IPv6 network (AS), for the IPv6 AS, the
> ASBRs support dual stack. To setup an end-to-end IPv4 TE LSP, the ASBRs to
> need to advertise their IPv4 TE Router ID within the domain. Is this case
> valid?

[Les:] My point is that if you need to "advertise" the IPv4 Router ID you simply put it in the fixed part of TLV 242 (and/or TLV 141). You don't need to use the sub-TLV.
If you also want to advertise the IPv6 Router ID in the same TLV you then use the IPv6 Router ID sub-TLV i.e., nothing in 4971bis prohibits you from sending IPv6 Router ID sub-TLV when the router id in TLV 242 is a valid IPv4 Router ID (NOT 0.0.0.0).

   Les

> 
> Best regards,
> Mach
> 
> >
> > Note also that to resolve the TLV 141 issue we need to define the
> > equivalent of TLV242/sub-TLV 12 for TLV 141.
> >
> >    Les
> >
> >
> >
> > > If you read RFC 5316 Section 3.2 I think it is clear that the TLV
> > > 242 sub-TLVs defined there are meant to advertise what is in TLVs
> 134/140.
> > > [Uma]:  It's not that explicit, IMO. I am sure you are thinking of
> > > the implications from 5316 PoV if we make it explicit?
> > > > In various contexts this hole has been discussed multiple times
> > > > and today we have to have an IPv4 router ID have to be configured
> > > > even for IPv6-only deployments.
> > > > May be it's good disambiguate further this should be tied to TLV
> > > > 140 (RFC 6119); meaning the  sub-TLV 12 (RFC 5316) should be
> > > > matching to TLV 140 if both are present.
> > > > Thoughts?
> > > > --
> > > > Uma C.
> > > >
> > > > 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).
> > > >
> > > > To: Mach Chen; Stefano Previdi (sprevidi); Les Ginsberg
> > > > (ginsberg); Stefano Previdi (sprevidi); Les Ginsberg (ginsberg);
> > > > Mach Chen
> > > > (Guoyi)

---

From: Mach Chen <[email-masked]>
Date: Fri, 9 Oct 2015 02:37:37 +0000

Les,

> Sent: Friday, October 09, 2015 10:15 AM
> To: Mach Chen; Uma Chunduri; ISIS-WG
> > ASBRs support dual stack. To setup an end-to-end IPv4 TE LSP, the
> > ASBRs to need to advertise their IPv4 TE Router ID within the domain.
> > Is this case valid?
> 
> [Les:] My point is that if you need to "advertise" the IPv4 Router ID you simply
> put it in the fixed part of TLV 242 (and/or TLV 141). You don't need to use the
> sub-TLV.
> If you also want to advertise the IPv6 Router ID in the same TLV you then use
> the IPv6 Router ID sub-TLV i.e., nothing in 4971bis prohibits you from sending
> IPv6 Router ID sub-TLV when the router id in TLV 242 is a valid IPv4 Router ID
> (NOT 0.0.0.0).

Indeed.

Best regards,
Mach 
> > > > If you think that RFC 5316 is not explicit enough we can discuss
> > > > the best way to clarify that. I am not sure that rfc4971bis is the
> > > > best place to do that - but we can certainly discuss.
> > > >
> > > > > and today we have to have an IPv4 router ID have to be
> > > > > configured even for IPv6-only deployments.
> > > > > 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
> > > > >

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Oct 2015 23:32:38 +0000

Les,

In-line [Uma]:

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, October 08, 2015 4:37 PM
To: Uma Chunduri; ISIS-WG
Cc: Stefano Previdi (sprevidi); Mach Chen ([email-masked])
Subject: RE: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

Uma -

[Uma]:  Agree. Basically  the 32-bit ID in TLV141 for v4 has to be matching to TLV 130, if TE is enabled, yes.

[Uma]: Yes.

   Les

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 12 Oct 2015 08:27:25 +0000

Hi Les,

> Sent: Thursday, October 08, 2015 12:04 PM
> To: ISIS-WG
> 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).
> 

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)?

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 12 Oct 2015 08:52:58 +0000

By the way, some previous discussions related to this thread (https://www.ietf.org/mail-archive/web/ospf/current/msg06940.html) may be worthwhile to be reviewed.

Best regards,
Xiaohu 

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Monday, October 12, 2015 4:27 PM
> > 1)New text at the beginning of Section 3 defining how to use the TLV
> > when no
> > IPv4 Router ID is present
> 
> 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)?
> 
> Best regards,
> Xiaohu
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Oct 2015 12:38:46 +0000

Xiaohu -

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Monday, October 12, 2015 1:27 AM
> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Oct 2015 12:40:40 +0000

Xiaohu -

The requirements of routerID in IS-IS are different than in OSPF. In IS-IS routerID MUST be a reachable address (as per RFC 5305 and RFC 6119).
And RFC 5316 already defined sub-TLVs to advertise router ID in TLV 242.

   Les

> Sent: Monday, October 12, 2015 1:53 AM
> To: Xuxiaohu; Les Ginsberg (ginsberg); ISIS-WG
> By the way, some previous discussions related to this thread
> (https://www.ietf.org/mail-archive/web/ospf/current/msg06940.html) may
> be worthwhile to be reviewed.
> 
> Best regards,
> Xiaohu
> 
> > 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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 13 Oct 2015 02:31:41 +0000

Hi Les,

> Sent: Monday, October 12, 2015 8:39 PM
> To: Xuxiaohu; ISIS-WG
> [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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Oct 2015 04:39:37 +0000

Xiaohu -

> Sent: Monday, October 12, 2015 7:32 PM
> > > > 1)New text at the beginning of Section 3 defining how to use the
> > > > TLV when no
> > > 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
> > [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:] 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.
> 
> It would cause backwards compatibility issues to those RFC4971-compatible
> routers according to the following specification:
> 
[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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 13 Oct 2015 06:54:37 +0000

Hi Les,

> Sent: Tuesday, October 13, 2015 12:40 PM
> To: Xuxiaohu; ISIS-WG
> > Subject: Re: [Isis-wg] FW: New Version Notification for
> > > > 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
> > > [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:] 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-
> > It would cause backwards compatibility issues to those
> > RFC4971-compatible routers according to the following specification:
> >
> [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

> > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-isis-rfc4971
> > > > > bi
> > > > > s-00.txt
> > > > > Status:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 Oct 2015 18:50:01 +0000

Xiaohu -

> Sent: Monday, October 12, 2015 11:55 PM
> > > > > > From: Isis-wg [mailto:[email-masked]] On Behalf Of
> > > > > > Les Ginsberg
> > > > > > (ginsberg)
> > > > > > 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).
> > > > > >
> > > > > > 1)New text at the beginning of Section 3 defining how to use
> > > > > > the TLV when no
> > > > > 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
> > > > - 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:] 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.,
> > 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
> 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

> > > > > > (ginsberg); Stefano Previdi (sprevidi); Les Ginsberg
> > > > > > (ginsberg); Mach Chen
> > > > > > (Guoyi)
> > > > > > of submission until the htmlized version and diff are
> > > > > > available at
> > > tools.ietf.org.
> > > > > >
> > > > > > The IETF Secretariat
> > > > > >

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 15 Oct 2015 01:37:43 +0000

Hi Les,

> Sent: Thursday, October 15, 2015 2:50 AM
> To: Xuxiaohu; ISIS-WG
> > > > Xuxiaohu
> > > > > > > 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).
> > > > > > >
> > > > > > 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
> > > > > >    the router generates any capability TLVs with domain
> > > > > > flooding
> > scope,
> > > > > > Or did you also want to know at least one routable IP address
> > > > > > of a given router that generates a Router Capability TLV (see
> > > > > [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.
> > > > > - remembering that in the case of a leaked TLV 242 the
> > > TLV 242 SHOULD be different than what is advertised in TLV 134? If
> > > so, please explain why.
> > >
> > > > 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.
> > > >
> > > [Les:] For a router which does NOT support IPv4 - and therefore has
> > > no reachable IPv4 address assigned to any interface (including
> > > loopbacks)
> > > 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.
> > >
> > > 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.
> >
> > 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.
> >
> 

According to the following text from your previous reply

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

Does it mean the routable IP address sub-TLV of the ISIS Router Capability TLV is still necessary until " they have fully deployed a version which supports the bis extensions"?

Best regards,
Xiaohu

> > > > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-isis-rfc
> > > > > > > 49
> > > > > > > 71
> > > > > > > bi
> > > > > > > s-00.txt
> > > > > > > Status:
> > > > > > >    Intermediate System (IS-IS) TLV named CAPABILITY, formed
> > > > > > > of
> > > > multiple
> > > > > > > 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
> > > > > > >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Oct 2015 04:32:25 +0000

Xiaohu -

> Sent: Wednesday, October 14, 2015 6:38 PM
> > > > > > > > From: Isis-wg [mailto:[email-masked]] On Behalf
> > > > > > > > Of Les Ginsberg
> > > > > > > > (ginsberg)
> > > > > > > > how to use TLV 242 on a router which supports only IPv6
> > > > > > > > (has no
> > > > > > > > IPv4
> > > > > addresses).
> > > > > > > >
> > > > > > > > 1)New text at the beginning of Section 3 defining how to
> > > > > > > > use the TLV when no
> > > > > > > According to the definition of Router ID as defined in
> > > > > > > RFC4971 as
> > > follows:
> > > > > > >
> > > > > > > Or did you also want to know at least one routable IP
> > > > > > > address of a given router that generates a Router Capability
> > > > > > > TLV (see
> > > > > > 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
> > > > 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.
> > > >
> > > > > 01). That routable IP address could be identical to the TE
> > > > > router ID if
> > > assigned.
> > > > >    CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT
> > > > > have
> > the
> > > > [Les:] For a router which does NOT support IPv4 - and therefore
> > > > has no reachable IPv4 address assigned to any interface (including
> > > > loopbacks)
> > > > 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?
> > > >
> > > > 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
> > > > 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
> > [Les:] This was answered by my previous reply. Please read the
> > paragraph immediately preceding your question.
> 
> "...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..."
> 
> Does it mean the routable IP address sub-TLV of the ISIS Router Capability
> TLV is still necessary until " they have fully deployed a version which supports
> the bis extensions"?
> 

[Les:] If by " routable IP address sub-TLV of the ISIS Router Capability" you mean sub-TLV 11: IPv4 TE Router ID then read on.
If not, then stop and explain which other sub-TLV you actually mean.

There is no use for sub-TLV 11. There wasn't one before rfc4971bis draft and there isn't one after rfc4971bis draft. If we had all been smarter back when RFC 5316 was being written we would have realized that and never defined the sub-TLV.

Sub-TLV 12: IPv6 TE Router ID is quite useful - and rfc4971bis is taking advantage of that.

   Les

> > > > > > > >    Intermediate System (IS-IS) TLV named CAPABILITY,
> > > > > > > > formed of
> > > > > multiple
> > > > > > > >    sub-TLVs, which allows a router to announce its
> > > > > > > > capabilities
> > within

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 15 Oct 2015 07:42:50 +0000

Hi Les,

> Sent: Thursday, October 15, 2015 12:32 PM
> To: Xuxiaohu; ISIS-WG
> > > > > > > > > From: Isis-wg [mailto:[email-masked]] On
> > > > > > > > > Behalf Of Les Ginsberg
> > > > > > > > > (ginsberg)
> > > > > > > > > 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).
> > > > > > > > >
> > > > > > > > "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
> > > > > > > >    then the ID MUST also be unique within the IS-IS
> > > > > > > > routing
> > domain."
> > > > > > > >
> > > > > > > > "...The Router ID SHOULD be identical to the value
> > > > > > > > advertised in
> > the
> > > > > > > >    Engineering Router ID is assigned the Router ID SHOULD
> > > > > > > > be
> > > identical
> > > > > > > >    IS. If the originating node does not support IPv4, then
> > > > > > > > the
> > reserved
> > > > > > > > address of a given router that generates a Router
> > > > > > > > Capability TLV (see
> > > > > > > operators to assign yet another unique number to each node
> > > > > > > and then we need a way to correlate this number w the
> > > > > > > originating node
> > > > > > 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
> > > > > >    CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do
> > > > > > NOT have
> > > the
> > > > > > "...   A router that generates a CAPABILITY TLV MUST have a Router
> ID
> > > > that
> > > > > 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?
> > > > >
> > > > > - 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.
> > > > >
> > > > > 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
> > > > > 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
> > "...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..."
> >
> > Does it mean the routable IP address sub-TLV of the ISIS Router
> > Capability TLV is still necessary until " they have fully deployed a
> > version which supports the bis extensions"?
> >
> 
> [Les:] If by " routable IP address sub-TLV of the ISIS Router Capability" you mean
> sub-TLV 11: IPv4 TE Router ID then read on.

It means the Routable IP Address sub-TLV as defined in https://tools.ietf.org/html/draft-xu-isis-routable-ip-address

> There is no use for sub-TLV 11. There wasn't one before rfc4971bis draft and
> there isn't one after rfc4971bis draft. If we had all been smarter back when RFC
> 5316 was being written we would have realized that and never defined the
> sub-TLV.
> 

The value of the Routable IP Address sub-TLV as mentioned above could be identical to TE Router ID if TE Router ID is assigned. If TE router ID is not assigned, the value of the Routable IP Address could be identical to an IP interface address advertised by that originator. Meanwhile, there is no need to set the Router ID to 0.0.0.0. In other words, operators could assign the router ID as what they have done today. In this way, there is no compatible issue (e.g., an RFC4971-compatible router receive two TLV- 242s (with router id of 0.0.0.0) which are originated by two IPv6-only routers.). In addition, there is no need of enforcing the assignment of TE router ID even in the case where TE is not needed at all.

Best regards,
Xiaohu

> > > > > > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-isis
> > > > > > > > > -r
> > > > > > > > > fc
> > > > > > > > > 49
> > > > > > > > > 71
> > > > > > > > > bi
> > > > > > > > > s-00.txt
> > > > > > > > > Status:
> > > > > > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc4971
> > > > > > > bi
> > > > > > > s/
> > > > > > > > > Htmlized:
> > > > > > > > > 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
> > > > > > > > >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Oct 2015 02:12:57 +0000

Xiaohu -

> Sent: Thursday, October 15, 2015 12:43 AM
> > > > > > > > > > 1)New text at the beginning of Section 3 defining how
> > > > > > > > > > to use the TLV when no
> > > > > > > > > the router ID is just required to be a 32-bit number
> > > > > > > > > which is unique within the area or the domain.
> > > > > > > > >
> > > > > > > > >    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
> > > > > > > > [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.
> > > > > > > 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
> > > > > > 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?
> > > > > > > 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
> > > > > > > https://tools.ietf.org/html/draft-xu-isis-routable-ip-addres
> > > > > > > s- 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.
> > > > > > >
> > > > > > [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?
> > > > > >
> > > > > > which needs to advertise TLV 242. This could be done - but is
> > > > > > an unnecessary
> > > > > burden for deployment.
> > > > > > 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
> > > > > > the bis extensions. Then they can remove the IPv4 Router ID
> > > > > > and automatically enable the new
> > > > > functionality.
> > > > >
> > [Les:] If by " routable IP address sub-TLV of the ISIS Router
> > Capability" you mean sub-TLV 11: IPv4 TE Router ID then read on.
> It means the Routable IP Address sub-TLV as defined in
> https://tools.ietf.org/html/draft-xu-isis-routable-ip-address
>
[Les:] The functionality defined in  draft-xu-isis-routable-ip-address has been provided by the sub-TLVs defined in http://datatracker.ietf.org/doc/draft-ietf-isis-prefix-attributes/ . This was agreed upon by all parties and you are a co-author. :-)

This has nothing to do w rfc4971bis. The issue rfc4971bis is addressing is how to identify the source of TLV 142 when you don't have any IPv4 support.

   Les

> > There is no use for sub-TLV 11. There wasn't one before rfc4971bis
> > draft and there isn't one after rfc4971bis draft. If we had all been
> > smarter back when RFC
> > 5316 was being written we would have realized that and never defined
> > the sub-TLV.
> >
> The value of the Routable IP Address sub-TLV as mentioned above could be
> identical to TE Router ID if TE Router ID is assigned. If TE router ID is not
> assigned, the value of the Routable IP Address could be identical to an IP
> interface address advertised by that originator. Meanwhile, there is no need
> to set the Router ID to 0.0.0.0. In other words, operators could assign the
> router ID as what they have done today. In this way, there is no compatible
> issue (e.g., an RFC4971-compatible router receive two TLV- 242s (with router
> id of 0.0.0.0) which are originated by two IPv6-only routers.). In addition,
> there is no need of enforcing the assignment of TE router ID even in the case
> where TE is not needed at all.
> 
> Best regards,
> Xiaohu
> 
> >    Les
> >
> > > Best regards,
> > > Xiaohu
> > >
> > > >    Les
> > > >
> > > > > Best regards,
> > > > > Xiaohu
> > > > >
> > > > > >    Les
> > > > > >
> > > > > > > Best regards,
> > > > > > > Xiaohu
> > > > > > >
> > > > > > > >    Les
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Xiaohu
> > > > > > > > >
> > > > > > > > > > To: Mach Chen; Stefano Previdi (sprevidi); Les
> > > > > > > > > > Ginsberg (ginsberg); Stefano Previdi (sprevidi); Les
> > > > > > > > > > Ginsberg (ginsberg); Mach Chen
> > > > > > > > > > (Guoyi)
> > > > > > > > https://tools.ietf.org/html/draft-ginsberg-isis-rfc4971bis
> > > > > > > > -0
> > > > > > > > 0
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Abstract:
> > > > > > > > > >    This document defines a new optional Intermediate
> > > > > > > > > > System
> > to

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Oct 2015 02:57:15 +0000

Hi Les,

> Sent: Friday, October 16, 2015 10:13 AM
> To: Xuxiaohu; ISIS-WG
> > > > > > > > Of Xuxiaohu
> > > > > > > > > > > 1)New text at the beginning of Section 3 defining
> > > > > > > > > > > how to use the TLV when no
> > > > > > > > > >    the router generates any capability TLVs with
> > > > > > > > > > domain flooding
> > > > > > scope,
> > > > > > > > > >    value 0.0.0.0 MUST be used in the Router ID field
> > > > > > > > > > and the IPv6
> > > TE
> > > > > > > > > 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
> > > > > > > > > - 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
> > > > > > > > "... If the originating node does not support IPv4, then
> > > > > > > > the
> > reserved
> > > > > > > >    CAPABILITY TLVs which have a Router ID of 0.0.0.0 and
> > > > > > > > do NOT have
> > > > > the
> > domain.
> > > > > > > nor would it have a reachable IPv4 address (TLV 132). So
> > > > > > > what value would be
> > > > used?
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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 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?
> > > > IPv4 Router ID (as they MUST today) until they have fully deployed
> > > > a version which supports the bis extensions..."
> > > >
> > > > Capability TLV is still necessary until " they have fully deployed
> > > > a version which supports the bis extensions"?
> > > >
> > >
> [Les:] The functionality defined in  draft-xu-isis-routable-ip-address has been
> provided by the sub-TLVs defined in
> http://datatracker.ietf.org/doc/draft-ietf-isis-prefix-attributes/ . This was agreed
> upon by all parties and you are a co-author. :-)

How to identify the source (i.e., a routable IP address) of TLV242 can be addressed by draft-xu-isis-routable-ip-address NO MATTER IPv4 is supported or not. More specifically, the source (i.e., a routable IP address) of TLV242 is identified by the Routable IP address sub-TLV of that TLV. There is no need to change the current usage of the 32-bit Router ID field of TLV242. That's to say, the 32-bit Router ID could be identical to the IPv4 TE router ID, an IPv4 interface address or just 32-bit integer as long as it's unique within the area or domain scope. Therefore, it would not cause any compatible issue as the bis extension does (e.g., an RFC4971-compatible router receive two TLV- 242s (with router id of 0.0.0.0) which are originated by two IPv6-only routers.). In addition, there is no need of enforcing the assignment of TE router ID even in the case where TE is not needed at all.

In contrast, draft-ietf-isis-prefix-attributes doesn't address the above issue very well (i.e., to identify the source of TLV242) due to the following reasons: The IPv4/IPv6 Source Router ID as defined in draft-ietf-isis-prefix-attributes MUST be identical to IPv4/IPv6Traffic Engineering router ID (TLV134/140). However, according to the current specification of TLV242 [RFC4971], there is no field to contain the IPv4/IPv6 TE router ID. As a result, it's impossible to correlate the routable IP addresses contained in IPv4/IPv6 reachability TLVs with TLV242. In other words, draft-ietf-isis-prefix-attributes ALONE could not address the above issue (i.e., to identify the source of TLV242.). Instead, it depends on the bis extension which enforces the containing of TE router ID within TLV242. However, as said before, it's a RFC4971-incompatible way to identify the source of TLV242. in contrast, draft-xu-isis-routable-ip-address describes a RFC4971-compatible way to identify the source of TLV-242. In a words, until all routers have been upgraded to support the bis extension, using the Routable IP Address sub-TLV as defined in draft-xu-isis-routable-ip-address is still a valid way to indicate the source of TLV242. Don't you think so?

Best regards,
Xiaohu

> This has nothing to do w rfc4971bis. The issue rfc4971bis is addressing is how to
> identify the source of TLV 142 when you don't have any IPv4 support.

> > The value of the Routable IP Address sub-TLV as mentioned above could
> > be identical to TE Router ID if TE Router ID is assigned. If TE router
> > ID is not assigned, the value of the Routable IP Address could be
> > identical to an IP interface address advertised by that originator.
> > Meanwhile, there is no need to set the Router ID to 0.0.0.0. In other
> > words, operators could assign the router ID as what they have done
> > today. In this way, there is no compatible issue (e.g., an
> > RFC4971-compatible router receive two TLV- 242s (with router id of
> > 0.0.0.0) which are originated by two IPv6-only routers.). In addition,
> > > > > > > > > > > https://www.ietf.org/internet-drafts/draft-ginsberg-
> > > > > > > > > > > is
> > > > > > > > > > > is
> > > > > > > > > > > -r
> > > > > > > > > > > fc
> > > > > > > > > > > 49
> > > > > > > > > > > 71
> > > > > > > > > > > bi
> > > > > > > > > > > s-00.txt
> > > > > > > > > > > Status:
> > > > > > > > > https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc
> > > > > > > > > 49
> > > > > > > > > 71
> > > > > > > > > bi
> > > > > > > > > s/
> > > > > > > > > > > Htmlized:
> > > > > > > > > > > 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 [email-masked]