[Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Chris and Acee, and everyone,



I would like to request working group adoption of "Topology-Transparent 
Zone"

(TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .


This draft comprises the following solutions for helping to improve 
scalability:

1) abstracting a zone to a single pseudo node in IS-IS,

2) abstracting a zone to a single pseudo node in OSPF,

3) abstracting a zone to zone edges' full mess in IS-IS, and

4) transferring smoothly between a zone and a single pseudo node.

A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or

non-backbone area).



When a network area becomes (too) big, we can reduce its size in the sense

of its LSDB size through abstracting a zone to a single pseudo node or

abstracting a few zones to a few pseudo nodes.



While a zone is being abstracted (or transferred) to a single pseudo node,

the network is stable. There is no or minimum service interruption.



After abstracting a few zones to a few pseudo nodes, if we want to 
reconstruct

them, we can transfer (or roll) any of the pseudo nodes back to its zone 
smoothly

with no or minimum service interruption.



We had a prototype implementation of abstracting a zone to zone edges' full

mess in OSPF. The procedures and related protocol extensions for transferring

smoothly from a zone to zone edges' full mess are implemented and tested.

A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess

without any routing disruptions. The routes on every router are stable while

the zone is being transferred to its edges' mess. It is very easy to operate

the transferring.



There are two other drafts for improving scalability: "Area Proxy for IS-IS"

(Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
short).



"Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03

abstracts an existing IS-IS L1 area to a single pseudo node.



"Flood Reflection" 
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

abstracts an existing IS-IS L1 area to its edges' connections via one or more

flood reflectors.



We believe that TTZ has some special advantages even though

Area Proxy and Flood Reflection are very worthy. We would like

to ask for working group adoption of TTZ.



Best Regards,

Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Yingzhen Qu]

+1 on “application-specific”. It is used in the draft, that’s how I got it in 
my YANG example.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" 
Date: Thursday, June 18, 2020 at 2:08 PM
To: John E Drake , Yingzhen Qu , 
"Les Ginsberg (ginsberg)" , "BRUNGARD, 
DEBORAH A" , The IESG 
Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
, "Acee Lindem (acee)" , 
"draft-ietf-isis-te-...@ietf.org" , 
"lsr@ietf.org" 
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

John –

Yes – I like “Application-Specific” better. This matches the term we use 
throughout the documents.

Thanx.

Les

From: John E Drake 
Sent: Thursday, June 18, 2020 1:37 PM
To: Yingzhen Qu ; Les Ginsberg (ginsberg) 
; Les Ginsberg (ginsberg) 
; BRUNGARD, DEBORAH A ; 
The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

I had mentioned “Application Specific”

Yours Irrespectively,

John



Juniper Business Use Only
From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Thursday, June 18, 2020 4:30 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Les,

The proposed new titles are much better than the old ones. I’m debating between 
“application-scoped” and “application-based”, but no strong opinion. It’s up to 
you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu mailto:yingzhen...@futurewei.com>>, 
"Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Yingzhen –

Thanx for providing the YANG example – and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) – but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Jeff Tantsura]

+1 to “Application-Specific”

Cheers,
Jeff
On Jun 18, 2020, 2:09 PM -0700, Les Ginsberg (ginsberg) 
, wrote:
> John –
>
> Yes – I like “Application-Specific” better. This matches the term we use 
> throughout the documents.
>
> Thanx.
>
>     Les
>
> From: John E Drake 
> Sent: Thursday, June 18, 2020 1:37 PM
> To: Yingzhen Qu ; Les Ginsberg (ginsberg) 
> ; Les Ginsberg (ginsberg) 
> ; BRUNGARD, DEBORAH A ; 
> The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> I had mentioned “Application Specific”
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
> From: Yingzhen Qu 
> Sent: Thursday, June 18, 2020 4:30 PM
> To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
> ; BRUNGARD, DEBORAH A ; 
> The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
> Hi Les,
>
> The proposed new titles are much better than the old ones. I’m debating 
> between “application-scoped” and “application-based”, but no strong opinion. 
> It’s up to you and Peter to decide a good name.
>
> Thanks,
> Yingzhen
>
> From: "Les Ginsberg (ginsberg)" 
> Date: Thursday, June 18, 2020 at 11:04 AM
> To: Yingzhen Qu , "Les Ginsberg (ginsberg)" 
> , "BRUNGARD, DEBORAH A" 
> , The IESG 
> Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
> , "Acee Lindem (acee)" , 
> "draft-ietf-isis-te-...@ietf.org" , 
> "lsr@ietf.org" 
> Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> Yingzhen –
>
> Thanx for providing the YANG example – and for taking on the additions to the 
> IGP YANG models.
>
> Regarding changing the titles of the documents, I see your point. The work 
> started because of issues related to different TE applications (RSVP-TE and 
> SR Policy) – but you are correct that the solution provided can be used by 
> applications that are NOT TE related.
>
> Peter and I are still mulling this over, but how about these for new titles?
>
> IS-IS Application-Scoped Link Attributes
> OSPF Application-Scoped Link Attributes
>
>    Les
>
>
>
>
> From: Yingzhen Qu 
> Sent: Wednesday, June 17, 2020 11:29 PM
> To: Les Ginsberg (ginsberg) ; BRUNGARD, 
> DEBORAH A ; The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> Hi Deborah and Les,
>
> From YANG model’s perspective, whether there is a default value is based on 
> the protocol definition and it is optional. For this case, if there is no 
> default value the following could be an example YANG definition:
>
>   choice te-app-op-mode {
>     mandatory "true";
>     leaf legacy {
>   type empty;
>     }
>     leaf transition {
>   type empty;
>     }
>     leaf app-specific{
>   type empty;
>     }
>     description
>   "Link attributes mode.";
>   }
>
> “mandatory true” is used here to make this configuration mandatory, which 
> means implementations supporting this draft need to explicitly config the 
> operation mode. I’ll add the YANG support of this feature for both OSPF and 
> ISIS into the next version of the augmentation drafts.
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
>
> BTW, I’m now wondering whether the title of the draft is precise? Instead of 
> “IS-IS TE Attributes per application”, maybe something like “IS-IS per 
> application link attributes”? considering more applications will be using the 
> sub-TLV and they may not be TE. Same for OSPF.
>
> Thanks,
> Yingzhen
>
> From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 
> 
> Date: Wednesday, June 17, 2020 at 4:19 PM
> To: "BRUNGARD, DEBORAH A" , The IESG 
> Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
> , "Acee Lindem (acee)" , 
> "draft-ietf-isis-te-...@ietf.org" , 
> "lsr@ietf.org" 
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
> Resent-From: 
>
> Deborah –
>
> We have a protocol extension that provides alternative ways of supporting 
> legacy applications.
>
> Under the conditions noted in Section 6.1, implementations have a choice as 
> to which advertisements they use.
> There is nothing in the document to specify which choice is the default – nor 
> should there be.
> To do so  implies that you believe that an implementation which is otherwise 
> compliant (i.e., it sends/receives TLVs in accordance with 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Les Ginsberg (ginsberg)]

John -

Yes - I like "Application-Specific" better. This matches the term we use 
throughout the documents.

Thanx.

Les

From: John E Drake 
Sent: Thursday, June 18, 2020 1:37 PM
To: Yingzhen Qu ; Les Ginsberg (ginsberg) 
; Les Ginsberg (ginsberg) 
; BRUNGARD, DEBORAH A ; 
The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

I had mentioned "Application Specific"

Yours Irrespectively,

John



Juniper Business Use Only
From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Thursday, June 18, 2020 4:30 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Les,

The proposed new titles are much better than the old ones. I'm debating between 
"application-scoped" and "application-based", but no strong opinion. It's up to 
you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu mailto:yingzhen...@futurewei.com>>, 
"Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Yingzhen -

Thanx for providing the YANG example - and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) - but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

>From YANG model's perspective, whether there is a default value is based on 
>the protocol definition and it is optional. For this case, if there is no 
>default value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

"mandatory true" is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I'll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[John E Drake]

I had mentioned "Application Specific"

Yours Irrespectively,

John



Juniper Business Use Only
From: Yingzhen Qu 
Sent: Thursday, June 18, 2020 4:30 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; BRUNGARD, DEBORAH A ; 
The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Les,

The proposed new titles are much better than the old ones. I'm debating between 
"application-scoped" and "application-based", but no strong opinion. It's up to 
you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu mailto:yingzhen...@futurewei.com>>, 
"Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Yingzhen -

Thanx for providing the YANG example - and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) - but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 BRUNGARD, DEBORAH A mailto:db3...@att.com>>; The IESG 
mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-isis-te-...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

>From YANG model's perspective, whether there is a default value is based on 
>the protocol definition and it is optional. For this case, if there is no 
>default value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

"mandatory true" is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I'll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I'm now wondering whether the title of the draft is precise? Instead of 
"IS-IS TE Attributes per application", maybe something like "IS-IS per 
application link attributes"? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Yingzhen Qu]

Hi Les,

The proposed new titles are much better than the old ones. I’m debating between 
“application-scoped” and “application-based”, but no strong opinion. It’s up to 
you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" 
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu , "Les Ginsberg (ginsberg)" 
, "BRUNGARD, DEBORAH A" , 
The IESG 
Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
, "Acee Lindem (acee)" , 
"draft-ietf-isis-te-...@ietf.org" , 
"lsr@ietf.org" 
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Yingzhen –

Thanx for providing the YANG example – and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) – but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu 
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to 

[Lsr] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

[Alvaro Retana]

Dear authors:

First of all, thank you for taking on this work!

I have some comments which I home will be easy to address -- please
see in-line below.  I will wait for a revised ID before starting the
IETF Last Call.

Before getting into the specifics, idnits came up with this warning:

=
     (Using the creation date from RFC3563, updated by this document, for
     RFC5378 checks: 2002-10-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)
=

This documents Updates several existing RFCs.  In general, the warning
means that we need to ask the authors of those RFCs, if published
before rfc5378, to grant BCP78 rights to the IETF Trust.  In this case
only rfc3563 is affected.  rfc5305 is not included because Tony Li was
one of the authors.

rfc6233 already Updated rfc3563, and it didn't include the disclaimer
for pre-RFC5378 work, which leads me to conclude that the BCP78 rights
were already granted at that time.  IOW, we don't need the disclaimer
for pre-RFC5378 work.

I'm writing all this here to have a record of this decision and to
give anyone in the WG the opportunity to raise concerns, if any.


Thanks!!

Alvaro.


[Line numbers from idnits.]


...
15  Abstract
...
27     This document when approved updates RFC3563, RFC5305, RFC6232, and
28     RFC6233.

[minor] s/This document when approved updates/This document updates


...
90  1.  Introduction

92     The Intermediate System to Intermediate System (IS-IS) protocol
93     utilizes Type/Length/Value (TLV) encoding for all content in the body
94     of Protocol Data Units (PDUs).  New extensions to the protocol are
95     supported by defining new TLVs.  In order to allow protocol
96     extensions to be deployed in a backwards compatible way an
97     implementation is required to ignore TLVs that it does not
98     understand.  This behavior is also applied to sub-TLVs, which are
99     contained within TLVs.

[minor] Add references to ISO10589 and rfc5305 in this first
paragraph: ...(IS-IS) protocol [ISO10589]...applied to sub-TLVs
[RFC5305]...


101    A corollary to ignoring unknown TLVs is having the validation of PDUs
102    be independent from the validation of the TLVs contained in the PDU.
103    PDUs which are valid MUST be accepted even if an individual TLV
104    contained within that PDU is invalid in some way.

[major] "MUST be accepted"   This is the behavior already specified in
ISO10589, right?   If so, then we shouldn't make it Normative here;
instead, s/MUST/must and add a reference to ISO10589.

Including that reference makes the first sentence in the next
paragraph unnecessary.


106    These behaviors are specified in existing protocol documents -
107    principally [ISO10589] and [RFC5305].  In addition, the set of TLVs
108    (and sub-TLVs) which are allowed in each PDU type is documented in
109    the TLV Codepoints Registry ( https://www.iana.org/assignments/isis-
110    tlv-codepoints/isis-tlv-codepoints.xhtml ) established by [RFC3563]
111    and updated by [RFC6233] and [RFC7356].

[minor] s/( 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
)/[TLV_CODEPOINTS]


113    This document is intended to clarify some aspects of existing
114    specifications and thereby reduce the occurrence of non-conformant
115    behavior seen in real world deployments.  Although behaviors
116    specified in existing protocol specifications are not changed, the
117    clarifications contained in this document serve as updates to RFC
118    3563 (see Section 2), RFC 5304, and RFC 6233 (see Section 3).

[minor] You missed RFC6232.

[major] s/5304/5305   Is §3.2 intended to update rfc5304?

[major] §3 has several subsections; can we please be specific above?
For example, §3.3 clearly updates rfc5305...§3.4 rfc6232...  I
suggested some text for §2/§3.3/§4.3; please add other explicit
indications of the updates.

[major] An important clarification, which I don't think is explicitly
made, is that the behavior for unknown is being applied to disallowed.
Not knowing and not expecting (= disallowed) are different things, but
this document is saying that the document treats them the same:
ignore.  I think adding a sentence about that relationship would help
a lot, and it may help us cover any cases that may have been missed (I
don't think there are any, but just in case)...maybe something like
this (I'm sure you can come up with much better words):

   This 

[Lsr] Deborah Brungard's Abstain on draft-ietf-isis-te-app-17: (with COMMENT)

[Deborah Brungard via Datatracker]

Deborah Brungard has entered the following ballot position for
draft-ietf-isis-te-app-17: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/



--
COMMENT:
--

Thanks for resolving my discuss on aligning SR terms with SPRING's work.

I remain unconvinced on backward compatibility with RSVP-TE, hence my abstain
ballot. Similar to other operators, I have serious concerns with operational
aspects and the unfair burden placed on operators. A simple on/off control
would have provided a much more elegant solution.

>From the discussion, this is obviously a multi-vendor agreement on their
preferred way, so while I disagree, I will not stand in the way.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Les Ginsberg (ginsberg)]

Yingzhen –

Thanx for providing the YANG example – and for taking on the additions to the 
IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work 
started because of issues related to different TE applications (RSVP-TE and SR 
Policy) – but you are correct that the solution provided can be used by 
applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu 
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[BRUNGARD, DEBORAH A]

Hi Acee, Les,

But the configuration control is not required, it is in small caps “will 
require”. So there is no guarantee it will be even present. Bruno and myself 
requested this should be stronger “MUST” or “REQUIRED”. And for “legacy” 
RSVP-TE applications, recommend a default, OFF, to ensure backward 
compatibility. Operators always needing to go into their config file (if the 
control is provided!) and ensure the values are set properly is not very user 
(operator) friendly or guarantees compatibility.

Just two simple changes (and it aligns section 6.1.1 with 6.3.3). As Bruno 
noted, this conversation is really frustrating. Especially when consider this 
is operational input by operators. But it is a familiar standoff - vendors want 
“flexibility” and operators want compatibility.

I’ll be clearing my Discuss on the ISIS, will also do on OSPF after the 
revision is uploaded fixing the TE, change to Abstain, saying operators have 
serious concerns with these documents. And let your AD decide if he wants to 
continue the discussion. I will be working with my TEAS chairs to ensure we are 
better aware of TEAS impacting documents being progressed in other groups.

Deborah

From: Acee Lindem (acee) 
Sent: Thursday, June 18, 2020 10:21 AM
To: Les Ginsberg (ginsberg) ; BRUNGARD, DEBORAH A 
; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
aretana.i...@gmail.com
Subject: Re: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Hi Les, Deborah,
I agree with Les. Especially since we’ve discussed and evolved these encodings 
in the LSR WG for over 3 years now. With the zero-length attribute bit mask, we 
essentially have the equivalent of the legacy advertisements, as well as all 
the limitations. As long as configuration is provided to dictate which 
encodings are used, I don’t see that the draft needs to specify the default.
Thanks,
Acee


From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Wednesday, June 17, 2020 at 7:18 PM
To: Deborah Brungard mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A mailto:db3...@att.com>>
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
The IESG mailto:i...@ietf.org>>
Cc: draft-ietf-isis-te-...@ietf.org; 
lsr-cha...@ietf.org; 
lsr@ietf.org; Acee Lindem (acee) 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Les, Deborah,
I agree with Les. Especially since we’ve discussed and evolved these encodings 
in the LSR WG for over 3 years now. With the zero-length attribute bit mask, we 
essentially have the equivalent of the legacy advertisements, as well as all 
the limitations. As long as configuration is provided to dictate which 
encodings are used, I don’t see that the draft needs to specify the default.
Thanks,
Acee


From: "Les Ginsberg (ginsberg)" 
Date: Wednesday, June 17, 2020 at 7:18 PM
To: Deborah Brungard , The IESG 
Cc: "draft-ietf-isis-te-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Acee Lindem , Alvaro Retana 
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A 
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Les-

To shortcut the discussion on the need for adding a default for “control”, 
these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require 
implementations to provide controls specifying which type of advertisements are 
to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”



[Les:] What is being described here is a “hitless transition strategy”. It is 
wrong to assume that the use of “enable” here means that the default is 
“disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy 
only.

None of this says or implies anything about what defaults are nor what config 
commands (if any) were needed to place the box in the state specified at Step 1.



This document is not a vendor configuration guide – and I do not want to make 
it one.



Les





If one is “enabling” then the default is “OFF”? So this document already 
assumes it. I don’t understand the reluctance to add also to section 6.1.1. 
When the YANG model is defined, this will be the config default. So either you 
specify now or later – later, may result in every vendor/platform having a 
different default if they don’t read section 6.3.3. That will be a major 
interoperability problem – even potentially among the same vendor for different 
platforms.



This same comment is for the OSPF document – it needs to specify a default.



More notes below.

Thanks,
Deborah

[Les:] “Legacy” refers to routers which do not support the extensions defined 
in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all 
of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Yingzhen Qu]

Hi Rob,

Thank you for your comments, and I agree with you that a sever implementation 
could use a deviation to add a default if needed.

This YANG will be augmenting base OSPF and ISIS model at protocol instance 
level.

Thanks,
Yingzhen

From: "Rob Wilton (rwilton)" 
Date: Thursday, June 18, 2020 at 2:29 AM
To: Yingzhen Qu , "Les Ginsberg (ginsberg)" 
, "BRUNGARD, DEBORAH A" , 
The IESG 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" , 
"Acee Lindem (acee)" , "draft-ietf-isis-te-...@ietf.org" 
, "aretana.i...@gmail.com" 

Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Yingzhen,

Just commenting for a YANG configuration perspective, I think that the YANG you 
propose is a reasonable approach.

In future, when it is clear the default behaviour should be app-specific, then 
the YANG could be changed to remove the mandatory true and add a default.  The 
combination of these changes would be classified as a backwards compatible 
change.  Note, a server implementation could also use deviations to equivalent 
effect to assign a default for a given implementation.

I don’t know whether this YANG would be configured per routing protocol 
instance, or something more specific (area or interface), but a hierarchical 
configuration model could be used if this configuration would otherwise be 
repetitive.

Regards,
Rob


From: iesg  On Behalf Of Yingzhen Qu
Sent: 18 June 2020 07:29
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr@ietf.org; lsr-cha...@ietf.org; Acee Lindem (acee) ; 
draft-ietf-isis-te-...@ietf.org; aretana.i...@gmail.com
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because 

[Lsr] Fwd: Devil's Advocate - Segment Routing, Why?

[Robert Raszuk]

Just FYI ...

An interesting discussion on nanog/cisco-nsp lists ... started innocent
with SRv6 bashing, now went into IGP - specifically ISIS territory  :)

-- Forwarded message -
From: Saku Ytti 
Date: Thu, Jun 18, 2020 at 12:43 PM
Subject: Re: Devil's Advocate - Segment Routing, Why?
To: Robert Raszuk 
Cc: Mark Tinka , na...@nanog.org ,
cisco-nsp NSP 


On Thu, 18 Jun 2020 at 13:28, Robert Raszuk  wrote:

> To your IGP point let me observe that OSPF runs over IP and ISIS does
not. That is first fundamental difference. There are customers using both
all over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with super
area) while in IETF there is ongoing work to extend ISIS to 8 levels. There
is a lot of fundamental differences between those two (or three) IGPs and I
am sure many folks on the lists know them. Last there is a lot of
enterprise networks happily using IPv4 RFC1918 all over their global WAN
and DCs infrastructure and have no reason to deploy IPv6 there any time
soon.  If you are serious about converging to a single IGP I would rather
consider look towards OpenR type of IGP architecture with message bus
underneath.


On Thu, 18 Jun 2020 at 13:43, Saku Ytti  wrote:

I view the 802.3 and CLNS as liability, not an asset. People who
actually route CLNS are a dying breed,  think just DCN of a legacy
optical.

Many platforms have no facilities to protect ISIS, any connected
attacker can kill the box. Nokia handles generated packets
classification by assigning DSCP value to  application then DSCP to
forwarding-class, which precludes from configuring ISIS qos. Very few
people understand how ISIS works before ISIS PDU is handed to them,
world from 802.3 to that is largely huge pile of hacks, instead of
complete CLNS stack implementation. There is no standard way to send
large frames over 802.3, so there is non-standard way to encap ISIS
for those links. Also due to lack of LSP roll-over, ISIS is subject to
a horrible attack vector which is very difficult to troubleshoot and
solve.

-- 
  ++ytti
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Hi Yingzhen,

Just commenting for a YANG configuration perspective, I think that the YANG you 
propose is a reasonable approach.

In future, when it is clear the default behaviour should be app-specific, then 
the YANG could be changed to remove the mandatory true and add a default.  The 
combination of these changes would be classified as a backwards compatible 
change.  Note, a server implementation could also use deviations to equivalent 
effect to assign a default for a given implementation.

I don’t know whether this YANG would be configured per routing protocol 
instance, or something more specific (area or interface), but a hierarchical 
configuration model could be used if this configuration would otherwise be 
repetitive.

Regards,
Rob


From: iesg  On Behalf Of Yingzhen Qu
Sent: 18 June 2020 07:29
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr@ietf.org; lsr-cha...@ietf.org; Acee Lindem (acee) ; 
draft-ietf-isis-te-...@ietf.org; aretana.i...@gmail.com
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those 

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Yingzhen Qu]

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" , The IESG 
Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
, "Acee Lindem (acee)" , 
"draft-ietf-isis-te-...@ietf.org" , 
"lsr@ietf.org" 
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: 

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A 
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Les-

To shortcut the discussion on the need for adding a default for “control”, 
these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require 
implementations to provide controls specifying which type of advertisements are 
to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”



[Les:] What is being described here is a “hitless transition strategy”. It is 
wrong to assume that the use of “enable” here means that the default is 
“disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy 
only.

None of this says or implies anything about what defaults are nor what config 
commands (if any) were needed to place the box in the state specified at Step 1.



This document is not a vendor configuration guide – and I do not want to make 
it one.



Les





If