Subject: [Lsr] Is it necessary to expand the IS-IS level to 8?

From: "Aijun Wang" <[email-masked]>
Date: Mon, 6 Jan 2020 12:02:48 +0800

Hi, Tony, Les and Paul: 

As I read the draft
https://tools.ietf.org/html/draft-ietf-lsr-isis-extended-hierarchy-00, and
notice the proposal to expand the reserved bits in "Circuit Type" to cover
the level 1-8 in ISIS domain.

Here I just want to know is it necessary to expand the IS-IS level to 8 and
occupy all the reserved bits in the PDU format?

As compared with the OSPF format, there is one field to describe the "Link
Type" (5 bits, currently define only four types). We want to use the
reserved bits in current "Circuit Type" of ISIS PDU format to fulfill the
similar tasks. 

Can this draft leave at least 2 reserved bits for this purpose? There are
many ways to tackle the scale of networks, who will design their network in
level 8 hierarchy? As I estimated, Level 4 may be the acceptable highest
network hierarchy.

Best Regards.

Aijun Wang

China Telecom

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Jan 2020 04:51:54 +0000

Aijun -

Regarding the number of levels, Tony responded to a similar comment several months ago - please see https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg

<snip>
> It seems not necessary to have 8 levels of hierarchies. 3 or at most 4 levels of hierarchies should be enough. IS-IS with 3 levels of hierarchies may support a network with 1k*1k*1k nodes, which is about 10^9 = 1 billion nodes. IS-IS with 4 levels of hierarchies may support a network with 1k*1k*1k*1k nodes, which is about 10^12 = 1 trillion nodes.

This is correct.  It's not absolutely necessary. However, as Robert mentioned, it does give the network designer flexibility to create the hierarchy that matches the needs of his network.  The cost of the additional levels is very small, given that we're considering adding any levels at all, so it seemed sensible to define all of the levels at once.

"From an architectural point of view, if a number isn't obviously too large, then it's probably too small."  - Ross Callon

<end snip>

Link type in OSPF is not at all the same thing as level in IS-IS - so I do not find that analogy appropriate:

>From https://tools.ietf.org/html/rfc2328 page 128

<snip>
Link type   Description       Link ID
                   __________________________________________________
                   1           Point-to-point    Neighbor Router ID
                               link
                   2           Link to transit   Interface address of
                               network           Designated Router
                   3           Link to stub      IP network number
                               network
                   4           Virtual link      Neighbor Router ID

                           Table 18: Link descriptions in the
                                      router-LSA.
<end snip>

   Les

From: Lsr <[email-masked]> On Behalf Of Aijun Wang
Sent: Sunday, January 05, 2020 8:03 PM
To: [email-masked]
Subject: [Lsr] Is it necessary to expand the IS-IS level to 8?

Hi, Tony, Les and Paul:

As I read the draft https://tools.ietf.org/html/draft-ietf-lsr-isis-extended-hierarchy-00, and notice the proposal to expand the reserved bits in "Circuit Type" to cover the level 1-8 in ISIS domain.
Here I just want to know is it necessary to expand the IS-IS level to 8 and occupy all the reserved bits in the PDU format?

As compared with the OSPF format, there is one field to describe the "Link Type" (5 bits, currently define only four types). We want to use the reserved bits in current "Circuit Type" of ISIS PDU format to fulfill the similar tasks.

Can this draft leave at least 2 reserved bits for this purpose? There are many ways to tackle the scale of networks, who will design their network in level 8 hierarchy? As I estimated, Level 4 may be the acceptable highest network hierarchy.

Best Regards.

Aijun Wang
China Telecom

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 6 Jan 2020 16:13:34 +0800

Hi, Les:

We just want to distinguish the passive interfaces from other normal
interfaces within ISIS domain.  It seems that the “Attribute Flags” that
described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
appropriate place to extend to carry such information.

If so, we can write one draft to define one more attribute flag to
accomplish this.

Or, is there any other way to fulfill this task? Originally, I want to reuse
the reserve bits before “Circuit Type” field.  It seems not the right
direction. 

And on the other hand, occupying all the reserved bits for the unnecessary
expansion is also not the right direction? 

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Les Ginsberg
(ginsberg)
发送时间: 2020年1月6日 12:52
收件人: Aijun Wang; [email-masked]
主题: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

Aijun –

Regarding the number of levels, Tony responded to a similar comment several
months ago – please see
https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg

<snip>

> It seems not necessary to have 8 levels of hierarchies. 3 or at most 4
levels of hierarchies should be enough. IS-IS with 3 levels of hierarchies
may support a network with 1k*1k*1k nodes, which is about 10^9 = 1 billion
nodes. IS-IS with 4 levels of hierarchies may support a network with
1k*1k*1k*1k nodes, which is about 10^12 = 1 trillion nodes.

This is correct.  It’s not absolutely necessary. However, as Robert
mentioned, it does give the network designer flexibility to create the
hierarchy that matches the needs of his network.  The cost of the additional
levels is very small, given that we’re considering adding any levels at
all, so it seemed sensible to define all of the levels at once.

“From an architectural point of view, if a number isn’t obviously too
large, then it’s probably too small.”  — Ross Callon

<end snip>

Link type in OSPF is not at all the same thing as level in IS-IS – so I do

<snip>

                               link

                               network

 

                                      router-LSA.

<end snip>

   Les

Hi, Tony, Les and Paul: 

As I read the draft
https://tools.ietf.org/html/draft-ietf-lsr-isis-extended-hierarchy-00, and
notice the proposal to expand the reserved bits in “Circuit Type” to cover
the level 1-8 in ISIS domain.

As compared with the OSPF format, there is one field to describe the “Link
Type” (5 bits, currently define only four types). We want to use the
reserved bits in current “Circuit Type” of ISIS PDU format to fulfill the
similar tasks. 

 

Best Regards.

Aijun Wang

China Telecom

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Jan 2020 11:57:38 +0100

Aijun,

> appropriate place to extend to carry such information.

Really ?

IMO much better place is to define new sub-TLV of TLV-22 and mark it there
as passive link.

Ref: https://tools.ietf.org/html/rfc5029

Now more interesting perhaps is to find out how ISIS is supposed to react
to such information. Or is the intention to carry it just as an opaque info
say for show commands use only ?

Thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Jan 2020 16:27:08 +0000

Aijun –

Hmmm…let me see if I understand you.

You and some other folks have an as yet unpublished idea to use some of the bits in circuit type field and therefore you are not happy that the hierarchy draft will use all of the circuit-type bits for levels.
Is this correct??

It is hard to comment on an unpublished idea – but I would point out that the field being used for levels is a field in the header of PDUs – and new PDUs at that. It is therefore hard to see how this is relevant to information about a particular interface which is always contained in a TLV – not in the PDU header.

If you are talking specifically about IIH PDUs, note that IIHs are never sent on passive interfaces.

But it is hard to comment on an idea that you have yet to publish.

   Les

From: Aijun Wang <[email-masked]>
Sent: Monday, January 06, 2020 12:14 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: 答复: [Lsr] Is it necessary to expand the IS-IS level to 8?

Hi, Les:

We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most appropriate place to extend to carry such information.
If so, we can write one draft to define one more attribute flag to accomplish this.

Or, is there any other way to fulfill this task? Originally, I want to reuse the reserve bits before “Circuit Type” field.  It seems not the right direction.

And on the other hand, occupying all the reserved bits for the unnecessary expansion is also not the right direction?

Best Regards.

Aijun Wang
China Telecom

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年1月6日 12:52
收件人: Aijun Wang; [email-masked]<mailto:[email-masked]>
主题: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

Aijun –

Regarding the number of levels, Tony responded to a similar comment several months ago – please see https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg

<snip>
> It seems not necessary to have 8 levels of hierarchies. 3 or at most 4 levels of hierarchies should be enough. IS-IS with 3 levels of hierarchies may support a network with 1k*1k*1k nodes, which is…

This is correct.  It’s not absolutely necessary. However, as Robert mentioned, it does give the network designer flexibility to create the hierarchy that matches the needs of his network.  The cost of the additional levels is very small, given that we’re considering adding any levels at all, so it seemed sensible to define all of the levels at once.

“From an architectural point of view, if a number isn’t obviously too large, then it’s probably too small.”  — Ross Callon

<end snip>

Link type in OSPF is not at all the same thing as level in IS-IS – so I do not find that analogy appropriate:

<snip>

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: Sunday, January 05, 2020 8:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] Is it necessary to expand the IS-IS level to 8?

Hi, Tony, Les and Paul:

As I read the draft https://tools.ietf.org/html/draft-ietf-lsr-isis-extended-hierarchy-00, and notice the proposal to expand the reserved bits in “Circuit Type” to cover the level 1-8 in ISIS domain.
Here I just want to know is it necessary to expand the IS-IS level to 8 and occupy all the reserved bits in the PDU format?

As compared with the OSPF format, there is one field to describe the “Link Type” (5 bits, currently define only four types). We want to use the reserved bits in current “Circuit Type” of ISIS PDU format to fulfill the similar tasks.

Best Regards.

Aijun Wang
China Telecom

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 7 Jan 2020 09:08:07 +0800

Hi, Robert:

Thanks for your information.

TLV-22 is used to describe the IS neighbor and the link between them. As for the passive interfaces, there may be no neighbor. 

It seems the sub-TLV within this TLV is not the appropriate place to put this information?

P.S. I changed the thread to reflect the conversion topic.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2020年1月6日 18:58
收件人: Aijun Wang
抄送: Les Ginsberg (ginsberg); [email-masked]
主题: Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

Aijun,

Really ?

IMO much better place is to define new sub-TLV of TLV-22 and mark it there as passive link.

Ref: https://tools..ietf.org/html/rfc5029 <https://tools.ietf.org/html/rfc5029> 

Now more interesting perhaps is to find out how ISIS is supposed to react to such information. Or is the intention to carry it just as an opaque info say for show commands use only ? 

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 7 Jan 2020 09:11:08 +0800

Hi, Les:

You are right.  I investigate again the PDU format/purpose and found the IIH is not the right place to carry this information.

Let’s discuss the passive interface solution in another thread “Methods to label the interfaces within ISIS”.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年1月7日 0:27
收件人: Aijun Wang; [email-masked]
主题: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

Aijun –

Is this correct??

   Les

Hi, Les:

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年1月6日 12:52
收件人: Aijun Wang; [email-masked]
主题: Re: [Lsr] Is it necessary to expand the IS-IS level to 8?

Aijun –

<snip>

 

<end snip>

<snip>

                               link

                               network

 

                                      router-LSA.

<end snip>

   Les

Hi, Tony, Les and Paul: 

 

Best Regards.

Aijun Wang

China Telecom

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 Jan 2020 11:13:58 +0100

Hi Aijun,

Right .. I took your email as an attempt/request to actually advertise
passive links in the first place.

May we know what difference does it make to you if reachable prefix is part
of an active vs passive interface from IGP point of view ?

Thx,
R.

On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang <[email-masked]> wrote:

> TLV-22 is used to describe the IS neighbor and the link between them. As
> for the passive interfaces, there may be no neighbor.
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Robert
> Raszuk
> *发送时间:* 2020年1月6日 18:58
> *收件人:* Aijun Wang
> *抄送:* Les Ginsberg (ginsberg); [email-masked]
> *主题:* Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?
>
>
>
> Aijun,
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 7 Jan 2020 18:56:49 +0800

Hi, Robert:
There are situations that we want to distinguish the passive interfaces from the normal interfaces. I will try to write one draft in recent days to describe it and for further discussion.

Thanks in advance.

Aijun Wang
China Telecom

> On Jan 7, 2020, at 18:14, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
> Right .. I took your email as an attempt/request to actually advertise passive links in the first place. 
> 
> May we know what difference does it make to you if reachable prefix is part of an active vs passive interface from IGP point of view ? 
> 
> Thx,
> R.
> 
> 
>> On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang <[email-masked]..cn> wrote:
>> Hi, Robert:
>> 
>>  
>> 
>> Ref: https://tools..ietf.org/html/rfc5029
>> 
>>  
>> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 10 Jan 2020 10:22:08 +0800

Hi, Les, Robert and other experts within LSR:

We have submitted the draft that related to the passive interface attribute, please review it at  https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00

If you are interested, we are also welcome you as the co-author to put forward it together.

Any comments are welcome.

Thanks in advance.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Aijun Wang
发送时间: 2020年1月7日 18:57
收件人: Robert Raszuk
抄送: Les Ginsberg (ginsberg); [email-masked]
主题: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Robert:

Thanks in advance.

Aijun Wang

China Telecom

Hi Aijun,

Thx,

R.

On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang <[email-masked]..cn <mailto:[email-masked]> > wrote:

Hi, Robert:

Best Regards.

Aijun Wang

China Telecom

Aijun,

Really ?

Thx,
R.

---

From: [email-masked]
Date: Thu, 9 Jan 2020 19:59:41 -0800

Hi Aijun,

Thank you for your draft.

First off, a ‘passive interface’ is a particular user interface phrase used by one very particular vendor.  It’s not a particularly accurate description, either. For example, a ‘passive’ interface implies that it might
accept protocol packets, but would not be active and send things on that interface.  That might have been meaningful in the distance vector days, but we’re decades past that now. The ’stub link’ designation 
sounds more accurate.

But that’s just naming.

As to mechanism, it seems to me that we already have the mechanisms that you want. Specifically, RFC 5029 already gives us a way of capturing link attributes. It would seem to me that all you need is a code point from that registry and you’d be done.  I’d recommend you direct your draft in that direction.

Regards,
Tony

> On Jan 9, 2020, at 6:22 PM, Aijun Wang <[email-masked]> wrote:
> 
> We have submitted the draft that related to the passive interface attribute, please review it at  https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00 <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00>
>  
> On Jan 7, 2020, at 18:14, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> Hi Aijun,
>>  
>> On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang <[email-masked]..cn <mailto:[email-masked]>> wrote:
>>> Hi, Robert:
>>>  
>>> 发件人: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 代表 Robert Raszuk
>>> 发送时间: 2020年1月6日 18:58
>>> 收件人: Aijun Wang
>>> 抄送: Les Ginsberg (ginsberg); [email-masked] <mailto:[email-masked]>
>>>> We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in https://tools.ietf.org/html/rfc7794#section-2.1 <https://tools.ietf.org/html/rfc7794#section-2.1> is the most appropriate place to extend to carry such information.
>>>  
>>> Really ?
>>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>_______________________________________________
> Lsr mailing list
> [email-masked]

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 10 Jan 2020 15:12:12 +0800

Hi, Tony:

Thanks for your suggestions.

If the behavior of “stub link” is same as that “passive interface”, for example, not sending thing on that interface, but can receive, we can modify the description later in the updated version of this draft.

For the link attributes that defined in RFC5029, as that stated in https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included in the TLV 22(Extended IS Reachability). 

As I read the IANA code point https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223, it notes this sub-TLV can be included in all of these TLVs (22,23,25,141,222,223). 

But, when the interface is configured as passive/stub, it seems that the above TLVs will not be advertised, because there is no IS neighbor on this passive link.  

TLV 141 “Inter-AS reachability information” seems be one appropriate TLV to include this sub-TLV, but it requires the IS-IS TE deployment, and is not suitable for describing the passive/stub link on edge router.

In summary, it seems put this attribute into the “Prefix Attribute Flags” sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is more applicable?

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2020年1月10日 12:00
收件人: Aijun Wang
抄送: Les Ginsberg; Robert Raszuk; [email-masked]
主题: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun,

sounds more accurate.

But that’s just naming.

Regards,

Tony

We have submitted the draft that related to the passive interface attribute, please review it at   <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00

Thanks in advance.

Best Regards.

Aijun Wang

China Telecom

Hi, Robert:

Thanks in advance.

Aijun Wang

China Telecom

On Jan 7, 2020, at 18:14, Robert Raszuk < <mailto:[email-masked]> [email-masked]> wrote:

Hi Aijun,

Thx,

R.

On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang < <mailto:[email-masked]> [email-masked]..cn> wrote:

Hi, Robert:

Best Regards.

Aijun Wang

China Telecom

发件人:  <mailto:[email-masked]> [email-masked] [mailto: <mailto:[email-masked]> [email-masked]] 代表 Robert Raszuk
发送时间: 2020年1月6日 18:58
收件人: Aijun Wang
抄送: Les Ginsberg (ginsberg);  <mailto:[email-masked]> [email-masked]
主题: Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

Aijun,

We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in  <https://tools.ietf.org/html/rfc7794#section-2.1> https://tools.ietf.org/html/rfc7794#section-2.1 is the most appropriate place to extend to carry such information.

Really ?

Ref:  <https://tools.ietf.org/html/rfc5029> https://tools..ietf.org/html/rfc5029

Thx,
R.

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

---

From: [email-masked]
Date: Thu, 9 Jan 2020 23:26:33 -0800

Hi Aijun,

> For the link attributes that defined in RFC5029, as that stated in https://tools.ietf.org/html/rfc5029#section-2 <https://tools.ietf.org/html/rfc5029#section-2>, this sub-TLV is included in the TLV 22(Extended IS Reachability). 
> As I read the IANA code point https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223>, it notes this sub-TLV can be included in all of these TLVs (22,23,25,141,222,223). 
>  

Fair point. Given that there is an IP address and prefix on that link, it would be very reasonable to advertise the Extended IP Reachability TLV (135). We would then need to make the link attributes sub-TLV applicable to this TLV (and it’s MT brother).

> In summary, it seems put this attribute into the “Prefix Attribute Flags” sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IP…

It would seem to me that what you’re describing is an attribute of a link, not of a prefix, thus I would favor it remaining a link attribute.

But that’s just me.  :-)

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jan 2020 13:26:55 +0100

Hi Tony,

I agree with you that essentially this is a link property (hence my earlier
hint towards 5029) so it makes it at least two of us recommending direction
towards 5029 now ;)

While we are at this perhaps it would be also useful to be able to
differentiate reachability on stub links vs virtual local interfaces. Today
in some implementations they are advertised after marking them as passive
int.

Thx
R.

On Fri, Jan 10, 2020, 08:26 <[email-masked]> wrote:

>
> Hi Aijun,
>
>
> For the link attributes that defined in RFC5029, as that stated in
> https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included
> in the TLV 22(Extended IS Reachability).
> As I read the IANA code point
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> , it notes this sub-TLV can be included in all of these TLVs
> (22,23,25,141,222,223).
>
> But, when the interface is configured as passive/stub, it seems that the
> above TLVs will not be advertised, because there is no IS neighbor on this
> passive link.
>
>
>
> Fair point. Given that there is an IP address and prefix on that link, it
> would be very reasonable to advertise the Extended IP Reachability TLV
> (135). We would then need to make the link attributes sub-TLV applicable to
> this TLV (and it’s MT brother).
>
>
> TLV 141 “Inter-AS reachability information” seems be one appropriate TLV
> to include this sub-TLV, but it requires the IS-IS TE deployment, and is
> not suitable for describing the passive/stub link on edge router.
>
> In summary, it seems put this attribute into the “Prefix Attribute Flags”
> sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP
> reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is
> more applicable?
>
>
>
> It would seem to me that what you’re describing is an attribute of a link,
> not of a prefix, thus I would favor it remaining a link attribute.
>
> But that’s just me.  :-)
>
> Tony
>
>

---

From: [email-masked]
Date: Fri, 10 Jan 2020 08:27:57 -0800

Hi Robert,

> I agree with you that essentially this is a link property (hence my earlier hint towards 5029) so it makes it at least two of us recommending direction towards 5029 now ;)

Is that rough consensus? ;-)

> While we are at this perhaps it would be also useful to be able to differentiate reachability on stub links vs virtual local interfaces. Today in some implementations they are advertised after marking them as passive int.

If we want to define another attribute for a loopback link vs a stub link vs a tunnel vs …. , I would support that direction.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 13 Jan 2020 16:39:05 +0800

Hi, Tony:

Is it reasonable to put the link attribute information into the “IP Reachability TLV”?

IMHO, such stub link is not the normal links within IGP domain.  Label the related prefix is coming from the passive/stub link seems also acceptable?

Best Regards.

Aijun Wang

China Telecom

发送时间: 2020年1月10日 15:27

Hi Aijun,

For the link attributes that defined in RFC5029, as that stated in  <https://tools.ietf.org/html/rfc5029#section-2> https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included in the TLV 22(Extended IS Reachability). 

As I read the IANA code point  <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223, it notes this sub-TLV can be included in all of these TLVs (22,23,25,141,222,223). 

 

 

But that’s just me.  :-)

Tony

---

From: [email-masked]
Date: Mon, 13 Jan 2020 07:59:59 -0800

Hi Anjun,

> IMHO, such stub link is not the normal links within IGP domain.  Label the related prefix is coming from the passive/stub link seems also acceptable?

Well, a passive interface is really configured so that you advertise the interface’s prefix.  Attaching the data that you want to the associated data seems reasonable to me.

There’s no good IS Neighbor advertisement to attach the sub-TLV to because there is no neighbor.

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 13 Jan 2020 16:03:14 +0000

Hi Aijun,
I guess the external use case for this is advertisement in BGP-LS for Network Management purposes?? There really isn’t IS-IS requirement to know whether or not an interface is a passive interface.
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Anjun,

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 13 Jan 2020 17:29:05 +0000

I agree with Acee that there is no requirement to identify an interface as passive – or (as suggested in this thread) as loopback or tunnel or stub…

Before debating the best encoding for information, it would be sensible to define the use case/requirements.
Simply having an advertisement that identifies an interface type isn’t sufficient to do anything useful IMO.

   Les

From: Acee Lindem (acee) <[email-masked]>
Sent: Monday, January 13, 2020 8:03 AM
To: [email-masked]; Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun,

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Tony Li <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Anjun,

Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 13 Jan 2020 10:32:14 -0800

Agree with Acee and Les

Cheers,
Jeff

---

From: Aijun Wang <[email-masked]>
Date: Tue, 14 Jan 2020 06:36:52 +0800

Hi, Acee, Les and Jeff:
IGP is used to transfer the topology information within the domain, and the stub/passive interface is the important part of one network, especially for the inter-AS topology.
Currently, we have not figured out other use cases to distinguish other interfaces type. But for stub/passive interfaces, it will be useful to flooding such information to other internal routers.
OSPF has already the corresponding consideration and specifications, isn’t it reasonable for ISIS to have such capabilities also?

Aijun Wang
China Telecom

> On Jan 14, 2020, at 02:41, Jeff Tantsura <[email-masked]> wrote:
> 
> 
> Agree with Acee and Les
> 
> Cheers,
> Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 13 Jan 2020 22:40:16 +0000

Hi Aijun,

From: Aijun Wang <[email-masked]>
Date: Monday, January 13, 2020 at 5:37 PM
To: Jeff Tantsura <[email-masked]>
Cc: Acee Lindem <[email-masked]>, Tony Li <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee, Les and Jeff:

A stub interface is not necessarily a passive interace.

OSPF doesn’t advertise that an interface is a passive interface. Others routing can’t distinguish a passive interface from any other stub link.

Thanks,
Acee

Aijun Wang
China Telecom

Cheers,
Jeff

   Les

Hi Aijun,

Hi Anjun,

Tony

---

From: Aijun Wang <[email-masked]>
Date: Tue, 14 Jan 2020 06:47:49 +0800

Hi, Acee:
As Tony suggested also before, we can change the description for “passive” to “stub” later.
Is that more acceptable then?

Aijun Wang
China Telecom

> On Jan 14, 2020, at 06:40, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 13 Jan 2020 23:06:06 +0000

Hi Aijun,

From: Aijun Wang <[email-masked]>
Date: Monday, January 13, 2020 at 5:48 PM
To: Acee Lindem <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, Tony Li <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee:

Yes – but I’d still like to know why this is needed.

Thanks,
Acee

Aijun Wang
China Telecom

Hi, Acee, Les and Jeff:

Thanks,
Acee

Aijun Wang
China Telecom

Cheers,
Jeff

   Les

Hi Aijun,

Hi Anjun,

Tony

---

From: Aijun Wang <[email-masked]>
Date: Tue, 14 Jan 2020 07:34:46 +0800

Hi, Acee:
Actually, currently it arises from the inter-AS topology management needs. It is not sufficient for BGP-LS to report only the interior connections information.
To report the edge connection information, the router within the IGP domain that run BGP-LS needs first to distinguish the stub link from the normal link.
There maybe exists other usages for this information, we will add them if we get it. Also welcome more examples/solutions from interested LSR experts.

Aijun Wang
China Telecom

> On Jan 14, 2020, at 07:06, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>