Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Hi Veerendranatha, Please check inline below. -Original Message- From: Veerendranatha Reddy V Sent: 19 August 2020 10:03 To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) ; lsr@ietf.org Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

This is a use case: The user plane of 5G is distributed, and MEC is deployed as part of the user plane to provide some functions at Access Aggregation Ring or Regional Aggregation Ring or at the border between Regional Aggregation Ring and the National Core. Using TTZ, MEC or part of it can be

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

I support it. Yes, indeed, this draft is sufficiently different from draft-ietf-lsr-isis-area-proxy-03 and should be advanced independently. Best regards, Richard From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee Lindem (acee)

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

Neither am I. Best regards, -Richard From: Kiran Makhijani Sent: Tuesday, August 18, 2020 1:51 PM To: Acee Lindem (acee) ; draft-chen-isis-...@ietf.org Cc: lsr@ietf.org Subject: RE: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt Hi, I am not aware of any

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

I’m not aware of any IPR associated this draft. Thanks, Yanhe From: Acee Lindem (acee) Sent: Tuesday, August 18, 2020 10:24 AM To: draft-chen-isis-...@ietf.org Cc: lsr@ietf.org Subject: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt Authors, The IETF IPRs

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Support as co-author. Thanks, Liu Les Ginsberg (ginsberg) 于2020年8月18日周二 下午3:52写道： > Huaimo – > > > > The question I and others have asked is “what can we do with zones that > cannot be done with areas?”. > > > > From the day several years ago when IS-IS TTZ was first presented, your > answer

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

I am not aware of any IPRs associated with the draft. Liu Kiran Makhijani 于2020年8月18日周二 下午1:51写道： > Hi, > > I am not aware of any undeclared IPR for this draft. > > -Kiran > > > > *From:* Acee Lindem (acee) > *Sent:* Tuesday, August 18, 2020 7:24 AM > *To:* draft-chen-isis-...@ietf.org >

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Huaimo - The question I and others have asked is "what can we do with zones that cannot be done with areas?". >From the day several years ago when IS-IS TTZ was first presented, your >answer has been "with zones you can hitlessly alter the topological >boundaries". My response has

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Les, > It is possible to merge/split areas without adjacency flaps. [HC]: While an existing area or zone is being abstracted as a single node or vice versa, there are the adjacency ups and downs. The areas merging/splitting without adjacency flaps has been done before this

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Huaimo - It is possible to merge/split areas without adjacency flaps. The technique has been known for many years. It requires careful planning - but it is quite feasible and has been done. You cannot justify the need for zones on this basis. Les From: Lsr On Behalf Of Huaimo Chen Sent:

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Les, > I see no need for “abstraction at arbitrary boundaries”. Areas work just fine. > IS-IS already has smooth transition capability for merging/splitting areas. [HC]: The smooth transition capability for merging/splitting areas in IS-IS will not reduce the service interruption while an

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Dear WG, The draft in question does not describe even a single practical use case. While it describes the mechanics on how to construct the new model of the abstraction it fails to prove we need it. Not everything which can be invented should be standardized or implemented therefore until the

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

As am I. Yours Irrespectively, John Juniper Business Use Only From: Lsr On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, August 18, 2020 5:07 PM To: Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

I see no need for “abstraction at arbitrary boundaries”. Areas work just fine. IS-IS already has smooth transition capability for merging/splitting areas. Given both of the points above, I see no value in “smooth transition to/from zone abstraction”. If these are the principal distinguishing

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

I support WG adoption of draft-chen-isis-ttz as experimental. Chris On Tue, Aug 18, 2020 at 9:17 AM Acee Lindem (acee) wrote: > > > Based on the discussions in the last meeting and on the mailing list > regarding draft-chen-isis-ttz-11, the chairs feel that there are enough > differences with

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

Hi, I am not aware of any undeclared IPR for this draft. -Kiran From: Acee Lindem (acee) Sent: Tuesday, August 18, 2020 7:24 AM To: draft-chen-isis-...@ietf.org Cc: lsr@ietf.org Subject: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt Authors, The IETF IPRs

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Tony – I am not “fighting”. I just found your interpretation very hard to follow. Moving on… Les From: Tony Li On Behalf Of tony...@tony.li Sent: Tuesday, August 18, 2020 12:33 PM To: Les Ginsberg (ginsberg) Cc: Robert Raszuk ; Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org;

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Les, There is no TLV called the Min Unidirectional Link Delay. If the document had said “The min delay of the Min/Max Unidirectional Link Delay” then there would be no confusion. Instead, it is the sloppy writing of ignoring the full name of the TLV that has created ambiguity. Now, Peter

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Support. Best Regards, Huaimo as a co-author From: Lsr on behalf of Acee Lindem (acee) Sent: Tuesday, August 18, 2020 10:16 AM To: lsr@ietf.org Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt Based on

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Les, > and conclude that this is really “Unidirectional Link Delay” is a leap that I cannot follow. I would never suggest to do that. My suggestion was to rename "Min Unidirectional Link Delay" to "minimum value of Min/Max Unidirectional Link Delay" and move on. Cheers, R. On Tue, Aug 18,

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Tony/Robert – Whatever clarification Peter may choose to make would be fine – but I do question your casual ignoring of adjectives.  There are three values being advertised: 33 - Unidirectional Link Delay 34 – Min/Max Unidirectional Link Delay Meaning two values are advertised in

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

I am not aware of any IPR for this document other than those disclosed. Best Regards, Huaimo From: Acee Lindem (acee) Sent: Tuesday, August 18, 2020 10:24 AM To: draft-chen-isis-...@ietf.org Cc: lsr@ietf.org Subject: LSR WG IPR Poll for "IS-IS

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the prefix-SID mapping advertised via it is for use for only intra or inter area prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF prefixes - regardless of the IA bit. The IA flag is only to

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[Contributor hat on.] Hi! I am not aware of any undeclared IPR for this document. Alvaro. On August 18, 2020 at 10:24:53 AM, Acee Lindem (acee) (acee=40cisco@dmarc.ietf.org) wrote: Authors, The IETF IPRs declarations submitted for

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Veerendranath, On 18/08/2020 16:40, Veerendranatha Reddy V wrote: Hi Authors, All, OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to distinguish between Intra and Inter Area scope prefixes. Whether any restrictions to not to use Prefix Range TLV for external/NSSA prefixes ?

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Robert, On 18/08/2020 19:10, Robert Raszuk wrote: Hi Tony, I am not sure what the deal is :) But fact is that we never defined a type which this draft is referring to "Min Unidirectional Link Delay" just does not exist in any IANA registry so even any search for that will fail. Perhaps

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Tony, I am not sure what the deal is :) But fact is that we never defined a type which this draft is referring to "Min Unidirectional Link Delay" just does not exist in any IANA registry so even any search for that will fail. Perhaps authors assumed that: Min/Max Unidirectional Link Delay

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Robert, Thank you, exactly. We just need a clarification of the document. I don’t understand why this is such a big deal. Tony > On Aug 18, 2020, at 9:22 AM, Robert Raszuk wrote: > > Les, > > I think this is not very obvious as Tony is pointing out. > > See RFC 8570 says: > >

[Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Hi Authors, All, OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to distinguish between Intra and Inter Area scope prefixes. Whether any restrictions to not to use Prefix Range TLV for external/NSSA prefixes ? For External Prefixes, we can able to use Prefix Range TLV by using

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Les, I think this is not very obvious as Tony is pointing out. See RFC 8570 says: TypeDescription 33 Unidirectional Link Delay 34 Min/Max Unidirectional Link Delay That means that is someone

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Tony – As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you are confused – nor why you got misdirected to code point 33. RFC 8570 (and its predecessor RFC 7810) define: 34 Min/Max Unidirectional Link Delay This sub-TLV contains two values: “Min Delay: This

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

I am not aware of any IPRs associated with the draft. Ning On Tue, Aug 18, 2020 at 9:24 AM Acee Lindem (acee) wrote: > Authors, > > > > The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified > here: > > > > https://datatracker.ietf.org/ipr/4029/ > > > > > > Are you aware of

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Peter, > section 5.1 of the draft-ietf-lsr-flex-algo says: > > Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. > > We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed > with other delay values (max, average). The problem is that that does not

[Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

Authors, The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here: https://datatracker.ietf.org/ipr/4029/ Are you aware of any other IPR that applies to draft-chen-isis-ttz? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas, Thanks for your response. Let us also wait for inputs from others in the WGs. One small bit. [KT] By giving different types for OSPF and ISIS, is the intention to troubleshoot routing preference selection (done based on "admin distance" between protocol selection in RIB)? Thomas>

[Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Based on the discussions in the last meeting and on the mailing list regarding draft-chen-isis-ttz-11, the chairs feel that there are enough differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it independently on the experimental track. These

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan, Thank you very much for the feedback. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types from RFC8402)? It's a simpler change to an existing element/field that makes it easier for

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Chris, I am not aware of any undisclosed IPR. thanks, Peter On 18/08/2020 01:30, Christian Hoppsprotocol= application/pgp-signature wrote: This begins a 2 week WG Last Call, ending after September 1st, 2020, for draft-ietf-lsr-flex-algo

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Tony, section 5.1 of the draft-ietf-lsr-flex-algo says: Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with other delay values (max, average). section 7.3. of ietf-isis-te-app says: Type