Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[John E Drake]

Support

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 6:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware 
> of any IPR that applies to these drafts.
> 
> Thanks,
> Chris.

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

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[John E Drake]

Support

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 6:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware 
> of any IPR that applies to these drafts.
> 
> Thanks,
> Chris.

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

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[John E Drake]

Cogent analysis of the situation

Sent from my iPhone

On Jul 27, 2022, at 6:39 PM, Les Ginsberg (ginsberg) 
 wrote:



[External Email. Be cautious of content]

(Preamble: All of what I am going to say I have said many times before – on the 
list – off the list – in private conversations – in WG meetings…
I don’t say this to start a discussion with the WG authors – it seems clear 
that we don’t agree and have no path to agreement.
My purpose in saying this is to respond to the ongoing existence of this draft 
and offering my opinion as to what action the WG should take.)

The mechanism defined in this draft is broken. Not only is it not backwards 
compatible – the PUA advertisements will be misinterpreted to mean the exact 
opposite of what is intended i.e., the intent is to signal that a prefix is 
unreachable, but you do so by using an advertisement which legacy nodes MUST 
interpret as meaning reachable. This is simply broken and should not be done.

The authors deserve credit for bringing the attention of the WG to the problem 
space – but the solution offered is not deployable. Given the long period of 
time during which this draft has been published and the many times it has been 
presented/discussed in the WG I think it is now time to say thank you to the 
authors for their work, but the WG is not interested in adopting this draft.

   Les


From: Lsr  On Behalf Of Ketan Talaulikar
Sent: Wednesday, July 27, 2022 1:36 AM
To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org
Cc: lsr 
Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

Hello Authors,

I am sharing some comments on the latest version of this document since we seem 
to have a packed agenda in LSR this time.

1) I notice that in the latest update of the draft, there is a big change to 
start using LSInfinity for indicating prefix unreachability (similar to 
draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree 
of convergence between the two drafts.

2) However, I then question the motivation of the authors to continue with the 
bad design of overloading Prefix Originator and the added capability stuff on 
top. I don't wish to repeat why that design was an absolute NO-GO for me and I 
am glad to see the authors acknowledge the problem with misrouting by 
implementations not supporting this specification. So I don't see the point of 
still retaining all that.

Thanks,
Ketan

___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BOlSdK7Bi4AiMHOkDAkQiJpIOJfYNcj0qrpU2SCoNERRIGtQSK7WvmUsq1G2qQWfkMk71PBRPJXzRZFS0M9DoNqIeHOMS_U$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John E Drake]

Les,

I'm happy with either 1 or 2.  It's good work and I think it will become 
important.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, June 14, 2022 4:01 PM
> To: John E Drake ; Les Ginsberg (ginsberg)
> ; John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; lsr@ietf.org
> Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> [External Email. Be cautious of content]
> 
> 
> John -
> 
> I would be inclined to agree with you - but...to my knowledge (happy to be
> corrected...) -
> 
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized mode 
> at
> present, since distributed mode requires standardization/multi-vendor
> implementation of at least one algorithm - which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And 
> since
> enthusiasm for this work has waned - perhaps only temporarily - it seems
> unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some
> degree "irresponsible".
> 
> I think there are then three viable paths:
> 
> 1)Continue to refresh the draft until such time as the gaps are closed or it
> becomes clear the work is more permanently not of interest 2)Capture the
> current contents as an Experimental RFC - noting the remaining work.
> 3)Capture the current contents as a Historic RFC - noting the remaining work.
> 
> I am not in favor of #3.
> I would be OK with #1 or #2.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ;
> > John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > draft-ietf-lsr-dynamic- flooding
> >
> > Hi,
> >
> > I don't understand why we don't just go through the normal Standards
> > track process.  I am sure there are any number of Standards track RFCs
> > which are published and which are neither widely implemented nor
> > widely deployed, but which may become so in the future.
> >
> > As Peter noted in the context of another draft, we are starting to see
> > extreme growth in the size of IGPs  which to me indicates that the
> > subject draft will be perceived as timely in the not too distant future.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Les Ginsberg
> > > (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > draft-ietf-lsr-
> > dynamic-
> > > flooding
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > John -
> > >
> > > Thanx for the information.
> > >
> > > I think what is relevant as regards the dynamic-flooding draft is
> > > that we
> > may be
> > > prematurely burying it.
> > > It is true, as Tony has stated, that the marketplace has not shown
> > > an active interest in deploying this technology - but I am not yet
> > > convinced that this is
> > the
> > > final disposition. As the scale of IGP networks increases and the
> > > use of fast- flooding is deployed, it may be that interest in 
> > > dynamic-flooding
> is revived.
> > >
> > > Publishing the draft as Experimental leaves open the possibilities.
> > > It could still be moved to Historic somewhere down the road if there
> > continues
> > > to be no deployment interest.
> > >
> > > I suppose it is also possible (as your post indicates) that we move
> > > it to
> > historic
> > > now and find a way to move it from historic if/when the need arises
> > > - but I frankly find such an approach very odd.
> > >
> > > I do not know why we are in a rush to "bury this". I think Acee has
> > > raised a
> > valid
> > > point - given that there was broad consensus on the protocol
> > > extensions themselves - that it would be good to formally preserve
> > > the dr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John E Drake]

Hi,

I don't understand why we don't just go through the normal Standards track 
process.  I am sure there are any number of Standards track RFCs which are 
published and which are neither widely implemented nor widely deployed, but 
which may become so in the future.  

As Peter noted in the context of another draft, we are starting to see extreme 
growth in the size of IGPs  which to me indicates that the subject draft will 
be perceived as timely in the not too distant future.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, June 14, 2022 12:19 PM
> To: John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> [External Email. Be cautious of content]
> 
> 
> John -
> 
> Thanx for the information.
> 
> I think what is relevant as regards the dynamic-flooding draft is that we may 
> be
> prematurely burying it.
> It is true, as Tony has stated, that the marketplace has not shown an active
> interest in deploying this technology - but I am not yet convinced that this 
> is the
> final disposition. As the scale of IGP networks increases and the use of fast-
> flooding is deployed, it may be that interest in dynamic-flooding is revived.
> 
> Publishing the draft as Experimental leaves open the possibilities.
> It could still be moved to Historic somewhere down the road if there continues
> to be no deployment interest.
> 
> I suppose it is also possible (as your post indicates) that we move it to 
> historic
> now and find a way to move it from historic if/when the need arises - but I
> frankly find such an approach very odd.
> 
> I do not know why we are in a rush to "bury this". I think Acee has raised a 
> valid
> point - given that there was broad consensus on the protocol extensions
> themselves - that it would be good to formally preserve the draft content. I 
> think
> Experimental is the best way to do that.
> 
> Les
> 
> > -Original Message-
> > From: John Scudder 
> > Sent: Tuesday, June 14, 2022 7:46 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; lsr@ietf.org
> > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > draft-ietf-lsr-dynamic- flooding
> >
> > Hi Les and all,
> >
> > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > So you are suggesting that we publish something that was never
> > > actually
> > published as an RFC as a "historic RFC"?
> > >
> > > The logic of that escapes me.
> >
> > It so happens I recently became aware that this publication track is
> > explicitly considered to be OK.
> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> l3RWY9vSXdEA8b
> >
> Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSwHRw
> YyGo$
> > historic-2014-07-20/ sez
> >
> > "An RFC may be published directly as Historic, with no earlier status
> > to change (see, for example, RFC 4870). This is usually done to
> > document ideas that were considered and discarded, or protocols that
> > were already historic when it was decided to document them. Those
> > publications are handled as are any other RFCs.”
> >
> > $0.02,
> >
> > —John
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!GYT66d5pSskUh-
> l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQ
> pFMmp2bSwFi578Bc$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[John E Drake]

Gyan,

I don't think we want a 1:1 mapping between NRP and FAD because it is a too 
restrictive and because it unnecessarily burns through FADs.  Rather, what I 
think we want is a set of resource SIDs, one per-NRP that are allocated by each 
node that is part of a FAD on each of its links that are currently part of the 
topology of that FAD.  There is then a label allocated by that node to 
represent the [FAD, NRP] tuple.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Gyan Mishra
Sent: Wednesday, May 18, 2022 12:51 AM
To: Dongjie (Jimmy) 
Cc: adr...@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[External Email. Be cautious of content]

Hi Jie

I reviewed the draft as well and it seems to parallel SR VTN MT draft  Enhanced 
VPN / VPN+  underpinning to IETF slice underlay TEAS NRP  mapped to an ISIS or 
OSPF MTID control plane instance.

Similarly here with this draft mapping of TEAS NRP to a Flex Algo FAD realizing 
of IETF network slice and now bundle members with this draft extensions to RFC 
8668 ISIS and OSPF draft
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03
 can now be mapped to an NRP.

VTN MT
https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt

Suggestion for s/VTN/NRP using updated TEAS Network slicing terminology.

This draft updates RFC 8668 for ISIS but should also update the OSPF draft 
above.

I think Adrian may have mentioned in his review I would refer to Flex Algo as 
IGP Flex Algo not SR Flex Algo throughout the draft as specified in the IGP 
Flex Algo draft.

I think it may or may not be the intention but I believe along with realizing 
an NRP using IGP Flex Algo mapping to L2 bundle member links, this draft also 
provides the context of realizing an NRP using Flex Algo and using the Flex 
Algo identifier as a way to reference or index the NRP per statement in section 
2.


If each VTN is associated with a unique Flex-Algo, the Flex-Algo identifier 
could be

reused as the identifier of the VTN in the control plane.

With the 1 to 1 mapping of Flex Algo to NRP you could also use the Flex Algo 
identifier to correlate the IETF Network slice NRP being instantiated by the 
NSC and possibly could use the Flex Algo identifier as the NRP ID.

Kind Regards

Gyan

On Tue, May 17, 2022 at 6:01 AM Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Adrian,

Thanks a lot for your detailed review. All your comments and suggestions look 
good and we will produce a new revision to incorporate them.

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org
> Cc: 
> draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
>
> Hi LSR and draft authors,
>
> I read this draft, and it seems to me that it provides a useful transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be 
> achieved
> with a very minor control plane extension.
>
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

>
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
>
> Best,
> Adrian
>
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/)
>  and network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[John E Drake]

Hi,

In the IETF context I have always associated 'data plane' with packet 
forwarding, so I think Peter's suggestion is fine.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Robert Raszuk
Sent: Thursday, April 14, 2022 5:21 AM
To: Peter Psenak 
Cc: Ketan Talaulikar ; Acee Lindem (acee) 
; draft-ietf-lsr-ip-flexa...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[External Email. Be cautious of content]

Hi Peter,

Term "data-plane" usually means physical resources links, switch fabric, ASIC 
etc ... so I am afraid it will also generate confusion with default data plane.

How about two alternatives:

- custom/logical topology
- logical-data-plane

Thx,
Robert.






On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Ketan,

On 13/04/2022 15:56, Ketan Talaulikar wrote:
> Hi Peter,
>
> I would still reiterate the need to clarify the usage of "application"
> terminology in the base FlexAlgo spec. We don't need to call it
> "data-plane", I was suggesting "forwarding mechanism" or it can be
> something else as well.

I will replace with data-plane. That's the best from what we have.

thanks,
Peter



>
> Just my 2c
>
> Thanks,
> Ketan
>
>
> On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak 
> mailto:ppse...@cisco.com>
> >> wrote:
>
> Hi Ketan,
>
> please see inline (##PP4):
>
>
> On 13/04/2022 10:52, Ketan Talaulikar wrote:
>  > Hi Peter,
>  >
>  > I will not press this point further if I am the only one that
> finds this
>  > complexity without any benefit. :-)
>  >
>  > Please check inline below for some clarifications with KT3.
>  >
>  >
>  > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak 
> mailto:ppse...@cisco.com>
> >
>  >  
>   >
>  > Hi Ketan,
>  >
>  >
>  > please see inline (##PP3):
>  >
>  > On 13/04/2022 06:00, Ketan Talaulikar wrote:
>  >  > Hi Peter,
>  >  >
>  >  > Please check inline below with KT2. I am trimming everything
>  > other than
>  >  > the one point of continuing debate.
>  >  >
>  >  >  >  >
>  >  >  >  > 2) The relationship between the algo usage
> for IP
>  > FlexAlgo
>  >  > and other
>  >  >  >  > data planes (e.g. FlexAlgo with SR) is not
> very clear.
>  >  > There arise
>  >  >  >  > complications when the algo usage for IP
> FlexAlgo
>  > overlap
>  >  > with other
>  >  >  >  > (say SR) data planes since the FAD is shared but
>  > the node
>  >  >  > participation
>  >  >  >  > is not shared. While Sec 9 suggests that we
> can work
>  >  > through these
>  >  >  >  > complications, I question the need for such
> complexity.
>  >  > The FlexAlgo
>  >  >  >  > space is large enough to allow it to be
> shared between
>  >  > various data
>  >  >  >  > planes without overlap. My suggestion would
> be to
>  > neither
>  >  > carve out
>  >  >  >  > parallel algo spaces within IGPs for various
> types of
>  >  > FlexAlgo data
>  >  >  >  > planes nor allow the same algo to be used by
> both
>  > IP and
>  >  > SR data
>  >  >  > planes.
>  >  >  >  > So that we have a single topology computation in
>  > the IGP
>  >  > for a given
>  >  >  >  > algo based on its FAD and data plane
> participation and
>  >  > then when it
>  >  >  >  > comes to prefix calculation, the results
> could involve
>  >  >  > programming of
>  >  >  >  > entries in respective forwarding planes
> based on the
>  >  > signaling of
>  >  >  > the
>  >  >  >  > respective prefix reachabilities. The
> coverage of these
>  >  > aspects in a
>  >  >  >  > dedicated section upfront will help.
>  >  >  >
>  >  >  > ##PP
>  >  >  > I strongly disagree.
>  >  >  >
>  >  >  > FAD is data-pane/app independent. Participation is
>  > data-plane/app
>  >  >  > dependent. Base flex-algo specification is very
> clear
>  > about
>  >  > that. That
>  >  >  > has 

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

[John E Drake]

I don’t see any response to the points Les made in the email thread, below.  
RFC5316 should be fine, so, as I indicated, your draft is redundant and 
dubious.  As an aside. I find it incredibly obnoxious and not within your remit 
to be instructing WG members what to do and I hope the WG chairs will curb your 
behavior.
y
Sent from my iPhone


On Feb 18, 2022, at 5:58 PM, Aijun Wang  wrote:
[External Email. Be cautious of content]


Hi, John:
If you follow Les, then also follow my responses to Les.

Aijun Wang
China Telecom


在 2022年2月19日，06:28，John E Drake  写道：

Hi,

I completely agree with the email from Les, below.  "Do no harm" is an 
insufficient reason to adopt a draft of redundant and dubious functionality.

Yours Irrespectively,

John


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, February 18, 2022 4:59 PM
To: Christian Hopps ; Peter Psenak

Cc: lsr@ietf.org
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316

[External Email. Be cautious of content]


Chris -

My objections to this draft are similar to Peter's - the use of a prefix to 
identify a
link is flawed - does not work in all cases. And the use case for the draft can 
be
met using RFC 5316.

It is also incorrect to state that a bis of RFC 5316 is required. That 
statement was
made based on the requirement of RFC 5316 to include AS numbers and the
concern that if BGP were not running that you would not have an AS #. But it
was pointed out in the thread that this issue could be addressed by using one of
the reserved ASNs (0 or 65535) or one of the private ASNs.

I also strongly object to your statement below:

" I've asked for cases that this draft would break things, not whether it has 
warts
or not."

This suggests (intentionally or not) that so long as a draft doesn't break 
anything
it is OK to consider it for adoption. I hope we have a higher bar than that.

In summary, this draft is at best redundant with RFC 5316 and introduces the use
of a flawed construct in doing so.
This should NOT be adopted.

  Les


-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Friday, February 18, 2022 5:48 AM
To: Peter Psenak 
Cc: lsr@ietf.org; Christian Hopps 
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316

[resent with correct CC's]

Peter Psenak  writes:

Chris,

I looked at ver-3.

It defines a new top-level TLV, that advertises prefix  and supports
all existing sub-TLVs defined for link advertisement ("IS-IS
Sub-TLVs for TLVs Advertising Neighbor Information").

And why? Because authors want to use common subnet to identify two
endpoints of
the same link.

Does not sound right to me.

That is not required though, and that is how they addressed the
unnumbered case.  but...

- we have more than enough TLVs in ISIS to advertise prefix already,
actually
too many of them. We don't need another one.

- using common subnet to identify two endpoints of the same link is wrong.
We
have existing mechanisms for that as as well.

This is rehashing the old arguments, we're passed that point now.

I've asked for cases that this draft would break things, not whether
it has warts or not.

Thanks,
Chris.
[as wg chair]

thanks,
Peter

On 18/02/2022 13:14, Christian Hopps wrote:
Peter Psenak  writes:

Chris,

the draft attempt to use the local subnet information for
identifying two endpoints of the same link. That seems wrong in itself. In
addition:
The -03 revision uses other methods to identify an inter-AS link
(the same that are used in RFC5316 if I'm not mistaken).

1) We have link local/remote IDs (and IP addresses) to pair the
two endpoints of the link in both OSPF and ISIS. We do not need
another
mechanism
for the same.
Tony Li (at least) seemed to think that it was useful to be able to
attach TE attributes to a link, not just to prefixes. Perhaps I've
missed this in the thread but what current mechanism (rfc?) are you
referring to, to identify
a
link and attach TE attributes to it?

2) What is proposed does not work for unnumbered links.
Can you clarify if you are saying this b/c you are refusing to look
at the -03 revision as "out of process" or does the -03 revision
also still fail on this point?
Thanks,
Chris.


thanks,
Peter



On 18/02/2022 05:45, Christian Hopps wrote:
[As WG Chair]
Hi LSR-WG,
As my co-chair has joined the draft as a co-author making the
call on
whether
we have rough consensus to adopt
draft-wang-lsr-stub-link-attributes-
02 now
falls to me alone.
I've reread the numerous emails on this adoption call and I see
some
support,
and a few objections, and most of the objections are not that
there is
no
problem to solve here, but they think this draft isn't the right
way to do
it
and a revision of RFC5316 could be done instead.
"A bird in the hand is worth two in the bush"
While it might be nice that there is another way to accomplish
things by re-using an existing TLV, that work 

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

[John E Drake]

Hi,

I completely agree with the email from Les, below.  "Do no harm" is an 
insufficient reason to adopt a draft of redundant and dubious functionality. 

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, February 18, 2022 4:59 PM
> To: Christian Hopps ; Peter Psenak
> 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
> 
> [External Email. Be cautious of content]
> 
> 
> Chris -
> 
> My objections to this draft are similar to Peter's - the use of a prefix to 
> identify a
> link is flawed - does not work in all cases. And the use case for the draft 
> can be
> met using RFC 5316.
> 
> It is also incorrect to state that a bis of RFC 5316 is required. That 
> statement was
> made based on the requirement of RFC 5316 to include AS numbers and the
> concern that if BGP were not running that you would not have an AS #. But it
> was pointed out in the thread that this issue could be addressed by using one 
> of
> the reserved ASNs (0 or 65535) or one of the private ASNs.
> 
> I also strongly object to your statement below:
> 
> " I've asked for cases that this draft would break things, not whether it has 
> warts
> or not."
> 
> This suggests (intentionally or not) that so long as a draft doesn't break 
> anything
> it is OK to consider it for adoption. I hope we have a higher bar than that.
> 
> In summary, this draft is at best redundant with RFC 5316 and introduces the 
> use
> of a flawed construct in doing so.
> This should NOT be adopted.
> 
> Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Christian Hopps
> > Sent: Friday, February 18, 2022 5:48 AM
> > To: Peter Psenak 
> > Cc: lsr@ietf.org; Christian Hopps 
> > Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
> >
> > [resent with correct CC's]
> >
> > Peter Psenak  writes:
> >
> > > Chris,
> > >
> > > I looked at ver-3.
> > >
> > > It defines a new top-level TLV, that advertises prefix  and supports
> > > all existing sub-TLVs defined for link advertisement ("IS-IS
> > > Sub-TLVs for TLVs Advertising Neighbor Information").
> > >
> > > And why? Because authors want to use common subnet to identify two
> > endpoints of
> > > the same link.
> > >
> > > Does not sound right to me.
> >
> > That is not required though, and that is how they addressed the
> > unnumbered case.  but...
> >
> > > - we have more than enough TLVs in ISIS to advertise prefix already,
> > actually
> > >  too many of them. We don't need another one.
> > >
> > > - using common subnet to identify two endpoints of the same link is wrong.
> > We
> > >  have existing mechanisms for that as as well.
> >
> > This is rehashing the old arguments, we're passed that point now.
> >
> > I've asked for cases that this draft would break things, not whether
> > it has warts or not.
> >
> > Thanks,
> > Chris.
> > [as wg chair]
> >
> > > thanks,
> > > Peter
> > >
> > > On 18/02/2022 13:14, Christian Hopps wrote:
> > >> Peter Psenak  writes:
> > >>
> > >>> Chris,
> > >>>
> > >>> the draft attempt to use the local subnet information for
> > >>> identifying two endpoints of the same link. That seems wrong in itself. 
> > >>> In
> addition:
> > >> The -03 revision uses other methods to identify an inter-AS link
> > >> (the same that are used in RFC5316 if I'm not mistaken).
> > >>
> > >>> 1) We have link local/remote IDs (and IP addresses) to pair the
> > >>> two endpoints of the link in both OSPF and ISIS. We do not need
> > >>> another
> > mechanism
> > >>> for the same.
> > >> Tony Li (at least) seemed to think that it was useful to be able to
> > >> attach TE attributes to a link, not just to prefixes. Perhaps I've
> > >> missed this in the thread but what current mechanism (rfc?) are you
> > >> referring to, to identify
> > a
> > >> link and attach TE attributes to it?
> > >>
> > >>> 2) What is proposed does not work for unnumbered links.
> > >> Can you clarify if you are saying this b/c you are refusing to look
> > >> at the -03 revision as "out of process" or does the -03 revision
> > >> also still fail on this point?
> > >> Thanks,
> > >> Chris.
> > >>
> > >>>
> > >>> thanks,
> > >>> Peter
> > >>>
> > >>>
> > >>>
> > >>> On 18/02/2022 05:45, Christian Hopps wrote:
> >  [As WG Chair]
> >  Hi LSR-WG,
> >  As my co-chair has joined the draft as a co-author making the
> >  call on
> > whether
> >  we have rough consensus to adopt
> >  draft-wang-lsr-stub-link-attributes-
> > 02 now
> >  falls to me alone.
> >  I've reread the numerous emails on this adoption call and I see
> >  some
> > support,
> >  and a few objections, and most of the objections are not that
> >  there is
> > no
> >  problem to solve here, but they think this draft isn't the right
> >  way to do
> > it
> >  and a revision of RFC5316 could be done instead.
> >  "A bird in the hand is worth two in the bush"
> > 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

This seems to be argument by emphatic assertion.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 7:45 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Christian Hopps 
; lsr-cha...@ietf.org; Tony Li ; lsr 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org; 
Peter Psenak 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

OK, then I can conclude that you have no more comments for my responses to Les.

Then, you and Les should notice that RFC5316 and RFC5392 are not appropriate to 
solve the scenarios that described in 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09*section-5.1__;Iw!!NEt6yMaO-gk!VOQyl9lKgK7cbrw7Q4Ahv-o_EsmlaIkdOxBy-L6hQIQqtq6ZSZf1MfJrFwa1oKU$>.
 I have given the reasons in previous mail.
Aijun Wang
China Telecom

On Jan 15, 2022, at 08:31, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

If I agree with Les, why do I need to repeat everything he has said?

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Peter Psenak mailto:ppse...@cisco.com>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; Tony Li 
mailto:tony...@tony.li>>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Hi, John:

Please gives concrete responses for my responses to Les’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/__;!!NEt6yMaO-gk!TD39mWfi5WWuFscpR6z6DLsI3GKpQfu32CCnr0iF7kcS5HnJ6Lpe_7l9L6PY0ac$>

If not, I would say both you and Les’s understanding of this draft is not 
correct.

Aijun Wang
China Telecom

On Jan 14, 2022, at 23:43, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draf

Re: [Lsr] BGP vs PUA/PULSE

[John E Drake]

I don’t think so.  Today things just work, at a given time scale.  What you 
said you are trying to do is reduce the time scale for detecting that an 
application on a node has failed.  However, conflating the health of a node 
with the health of an application on that node seems to be inherently flawed.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 7:40 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Robert Raszuk 
; Christian Hopps ; Shraddha Hegde 
; Tony Li ; Hannes Gredler 
; lsr ; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

When the node is up, all the following process are passed to the application 
layer. This is the normal procedures of the IGP should do.
According to your logic, IGP are solving the wrong problem now?
Aijun Wang
China Telecom

On Jan 15, 2022, at 08:30, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

Correct, but as Tony, Robert and I have noted, a node being up does not mean 
that an application on that node is up, which means that your proposed solution 
is probably a solution to the wrong problem.  Further, Robert’s solution is 
probably a solution to the right problem.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Friday, January 14, 2022 5:53 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Christian Hopps 
mailto:cho...@chopps.org>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi, John:
Please note if the node is down, the service will not be accessed.
We are discussing the “DOWN” notification, not the “UP” notification.
Aijun Wang
China Telecom

On Jan 15, 2022, at 00:25, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

Hi,

Comment inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Monday, January 10, 2022 7:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi Les,

> You seem focused on the notification delivery mechanism only.

Not really. For me, an advertised summary is like a prefix when you are dialing 
a country code. Call signaling knows to go north if you are calling a crab shop 
in Alaska.

Now such direction does not indicate if the shop is open or has crabs.

That info you need to get over the top as a service. So I am much more in favor 
to make the service to tell you directly or indirectly that it is available.

[JD]  Right.  Just because a node is up and connected to the network does not 
imply that a given application is active on it.

Best,
R.





On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert -

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.

We all agree the request is legitimate.

[LES:] It does not seem to me that everyone does agree on that – but I 
appreciate that you agree.

But do they realize that to practically employ what you are proposing (new PDU 
flooding) requires 100% software upgrade to all IGP nodes in the entire network 
? Do they also realize that to effectively use it requires data plane change 
(sure software but data plane code is not as simple as PI) on all ingress PEs ?

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works 
fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[John E Drake]

This is similar to the issue with the Down/Up proposal.  A single metric tells 
an ingress node nothing about the performance of or load on the individual 
applications at a given site.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 6:58 PM
To: John E Drake 
Cc: Robert Raszuk ; Gyan Mishra ; Les 
Ginsberg (ginsberg) ; Linda Dunbar 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

[External Email. Be cautious of content]

Hi, John:
Here I would also like to hear your own opinions. If not, please see my 
responses for both you and Robert:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc$>
 has introduced the “delay metric” into the IGP. Such metric may be variant in 
every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the 
stub-link’s/prefixes characteristics, it is the aggregate cost to the server 
that measured from the router.

All the factors that mentioned by Robert maybe the parameters that influences 
the performance of the server, which will be reflected in the aggregate cost.

Then, the conclusion is that IGP has now the capabilities to deal with the 
dynamics value(the change frequencies can certainly be controlled, thinking how 
we control the flapping interface)within the network , the aggregate cost or 
other quasi-static factor to the server at the edge of the network can also be 
considered together.
Such approaches can certainly let the IGP give more optimal behavior to forward 
the traffic to the appropriate destination, or follow an optimal path.
Aijun Wang
China Telecom

On Jan 14, 2022, at 23:49, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

Robert is correct on all points.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Friday, January 14, 2022 4:20 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

[External Email. Be cautious of content]

Gyan,

This is not a network discussion. There are well proven techniques to direct 
user sessions or user requests to a pool of servers deployed and operational. 
All provide robust services. Network plays very little to no role in that.

There are also lot's of factors involved in making that decision (CPU load, 
RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make 
IGP to carry it and make routing decisions (even if separate topology) based on 
that information.

I do not see this like a move into the right direction. That is my input.

Kind regards,
Robert.








On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Robert

Responses in-line



On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Gyan,

I see what the draft is trying to do now. /* I did not even consider this for 
the reason described below. */

But what you wrote requires little correction:

"So now the server you are on gets overloaded and a site cost gets advertised 
in the IGP at which point the connection receives a TCP reset"

if you s/connection/all connections/ then you quickly realize that what is 
proposed here is a disaster.

   Gyan>  Remember this is Anycast proximity based routing along with ECMP / 
UCMP flow based load balancing and most vendors modern routers support some 
sort of  x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if 
you have 10s of 100s of paths, the flows would be evenly distributed across all 
the paths.  Since it’s Anycast proximity each path leads to a different 
Application LB VIP and backend server.  So all the TCP connections would be 
uniformly distributed across all the paths.

Only the connections hashed to the path with overloaded server would get reset 
and it would be no different then if the server went down as the connections 
would get reset anyway in that case.

 In this case instead of being pinned to a bad connection you are now reset to 
a good connection resulting in better QOE for the end user and a Happy customer.

To me thats a positive not a negative.

 A good analogy would be let’s say you are on WIFI and on the same channel that 
your neighbors are on and have horrible bandwidth.  Do you stay on that bad 
channel and limp along all day or to you flip to an unused channel.

Another example is if you have a server that has run out of resources.  Do you 
fail production traffic off 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

If I agree with Les, why do I need to repeat everything he has said?

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Peter Psenak 
; Christian Hopps ; lsr-cha...@ietf.org; 
Tony Li ; lsr ; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Hi, John:

Please gives concrete responses for my responses to Les’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/__;!!NEt6yMaO-gk!TD39mWfi5WWuFscpR6z6DLsI3GKpQfu32CCnr0iF7kcS5HnJ6Lpe_7l9L6PY0ac$>

If not, I would say both you and Les’s understanding of this draft is not 
correct.

Aijun Wang
China Telecom

On Jan 14, 2022, at 23:43, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.
[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID.
Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link.
Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?
Why we must limit our deployment to the guideline of unsuitable RFCs?

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.
So there is no reason that this information should be bogus.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Li

Re: [Lsr] BGP vs PUA/PULSE

[John E Drake]

Correct, but as Tony, Robert and I have noted, a node being up does not mean 
that an application on that node is up, which means that your proposed solution 
is probably a solution to the wrong problem.  Further, Robert’s solution is 
probably a solution to the right problem.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 5:53 PM
To: John E Drake 
Cc: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Christian Hopps ; Shraddha Hegde 
; Tony Li ; Hannes Gredler 
; lsr ; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi, John:
Please note if the node is down, the service will not be accessed.
We are discussing the “DOWN” notification, not the “UP” notification.
Aijun Wang
China Telecom

On Jan 15, 2022, at 00:25, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

Hi,

Comment inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Monday, January 10, 2022 7:15 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi Les,

> You seem focused on the notification delivery mechanism only.

Not really. For me, an advertised summary is like a prefix when you are dialing 
a country code. Call signaling knows to go north if you are calling a crab shop 
in Alaska.

Now such direction does not indicate if the shop is open or has crabs.

That info you need to get over the top as a service. So I am much more in favor 
to make the service to tell you directly or indirectly that it is available.

[JD]  Right.  Just because a node is up and connected to the network does not 
imply that a given application is active on it.

Best,
R.





On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert -

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.

We all agree the request is legitimate.

[LES:] It does not seem to me that everyone does agree on that – but I 
appreciate that you agree.

But do they realize that to practically employ what you are proposing (new PDU 
flooding) requires 100% software upgrade to all IGP nodes in the entire network 
? Do they also realize that to effectively use it requires data plane change 
(sure software but data plane code is not as simple as PI) on all ingress PEs ?

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works 
fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade – but I agree a significant 
number of nodes have to be upgraded to at least support pulse flooding.


And with scale requirements you are describing it seems this would be 1000s of 
nodes (if not more). That's massive if compared to alternative approaches to 
achieve the same or even better results.

[LES:] Be happy to review other solutions if/when someone writes them up.
I think what is overlooked in the discussion of other solutions is that 
reachability info is provided by the IGP. If all the IGP advertises is a 
summary then how would individual loss of reachability become known at scale?
You seem focused on the notification delivery mechanism only.

   Les

Many thx,
Robert

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

Re: [Lsr] BGP vs PUA/PULSE

[John E Drake]

Hi,

Comment inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Robert Raszuk
Sent: Monday, January 10, 2022 7:15 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Aijun Wang 
; Shraddha Hegde ; Tony Li 
; Hannes Gredler ; lsr ; 
Peter Psenak (ppsenak) 
Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi Les,

> You seem focused on the notification delivery mechanism only.

Not really. For me, an advertised summary is like a prefix when you are dialing 
a country code. Call signaling knows to go north if you are calling a crab shop 
in Alaska.

Now such direction does not indicate if the shop is open or has crabs.

That info you need to get over the top as a service. So I am much more in favor 
to make the service to tell you directly or indirectly that it is available.

[JD]  Right.  Just because a node is up and connected to the network does not 
imply that a given application is active on it.

Best,
R.





On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert -

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler 
mailto:han...@gredler.at>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

We have received requests from real customers who both need to summarize AND 
would like better response time to loss of reachability to individual nodes.

We all agree the request is legitimate.

[LES:] It does not seem to me that everyone does agree on that - but I 
appreciate that you agree.

But do they realize that to practically employ what you are proposing (new PDU 
flooding) requires 100% software upgrade to all IGP nodes in the entire network 
? Do they also realize that to effectively use it requires data plane change 
(sure software but data plane code is not as simple as PI) on all ingress PEs ?

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works 
fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade - but I agree a significant 
number of nodes have to be upgraded to at least support pulse flooding.


And with scale requirements you are describing it seems this would be 1000s of 
nodes (if not more). That's massive if compared to alternative approaches to 
achieve the same or even better results.

[LES:] Be happy to review other solutions if/when someone writes them up.
I think what is overlooked in the discussion of other solutions is that 
reachability info is provided by the IGP. If all the IGP advertises is a 
summary then how would individual loss of reachability become known at scale?
You seem focused on the notification delivery mechanism only.

   Les

Many thx,
Robert

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[John E Drake]

Robert is correct on all points.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Robert Raszuk
Sent: Friday, January 14, 2022 4:20 AM
To: Gyan Mishra 
Cc: Les Ginsberg (ginsberg) ; Linda Dunbar 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

[External Email. Be cautious of content]

Gyan,

This is not a network discussion. There are well proven techniques to direct 
user sessions or user requests to a pool of servers deployed and operational. 
All provide robust services. Network plays very little to no role in that.

There are also lot's of factors involved in making that decision (CPU load, 
RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make 
IGP to carry it and make routing decisions (even if separate topology) based on 
that information.

I do not see this like a move into the right direction. That is my input.

Kind regards,
Robert.








On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Robert

Responses in-line



On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Gyan,

I see what the draft is trying to do now. /* I did not even consider this for 
the reason described below. */

But what you wrote requires little correction:

"So now the server you are on gets overloaded and a site cost gets advertised 
in the IGP at which point the connection receives a TCP reset"

if you s/connection/all connections/ then you quickly realize that what is 
proposed here is a disaster.

   Gyan>  Remember this is Anycast proximity based routing along with ECMP / 
UCMP flow based load balancing and most vendors modern routers support some 
sort of  x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if 
you have 10s of 100s of paths, the flows would be evenly distributed across all 
the paths.  Since it's Anycast proximity each path leads to a different 
Application LB VIP and backend server.  So all the TCP connections would be 
uniformly distributed across all the paths.

Only the connections hashed to the path with overloaded server would get reset 
and it would be no different then if the server went down as the connections 
would get reset anyway in that case.

 In this case instead of being pinned to a bad connection you are now reset to 
a good connection resulting in better QOE for the end user and a Happy customer.

To me thats a positive not a negative.

 A good analogy would be let's say you are on WIFI and on the same channel that 
your neighbors are on and have horrible bandwidth.  Do you stay on that bad 
channel and limp along all day or to you flip to an unused channel.

Another example is if you have a server that has run out of resources.  Do you 
fail production traffic off the server taking it out of rotation or let it stay 
as is and pray things get better.  This draft is a good example of how IGP can 
save the day with site metric.

Breaking all existing flows going to one LB to suddenly timeout and all go to 
the other LB(s) is never a technique any one would seriously deploy in a 
production network.

Gyan> Application load balancing can be done with DNS based GEO load balancing 
based on client and server IP database where you have more discrete control 
however the failover is much slower.

Leave alone that doing that has potential to immediately overload the other 
LB(s)/server(s) too.

Gyan> The idea with Anycast load balancing is that you may have 10 or even 100s 
of paths, so if one server fails the load can be evenly distributed based on 
statistical multiplexing algorithm calculated by the server teams engineering 
the sizing of the server clusters to ensure what you described won't happen.

For me the conclusion is that IGP transport level is not the proper layer to 
address the requirement.

Cheers,
Robert.


On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

Hi Les

Agreed.

My thoughts are that the context of the draft is based on an Anycast VIP 
address of a server which is proximity based load balancing and not necessarily 
ECMP/UCMP and only if the proximity is the same for multiple paths to the 
Anycast VIP would there be a ECMP/UCMP possibility.

Let's say if it's proximity based and one path is preferred, the flow will take 
that path.  So now the server you are on gets overloaded and a site cost gets 
advertised in the IGP at which point the connection receives a TCP reset and 
flow re-establishes on the alternate path based on the site cost and remains 
there until the server goes down or  gets overloaded or a better path comes 
along.

For ECMP case, ECMP has flow affinity so the flow will stay on the same path 
long lived until the connection terminates.

So now in ECMP case the flow hashed to a path and maintains its affinity to 
that path.  Now all of sudden the server gets overloaded and we get a better 
site cost advertised.  So now the 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang 
Cc: 'Peter Psenak' ; 'Christian Hopps' 
; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.
[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID.
Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link.
Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?
Why we must limit our deployment to the guideline of unsuitable RFCs?

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.
So there is no reason that this information should be bogus.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
like the Link Type Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1.
If you view them from the controller POV(the consumer of the BGP-LS 
information), you may know the below responses well.

[LES:] I called it a sub-TLV because that’s what it was in the previous version 
of the draft – before you invented a new top level TLV to avoid using TLV 141.
But regardless of the encoding details, my point is this information is not 
useful and not needed. There is no reason to advertise a loopback interface as 
a link. And there is no value in knowing whether the non-loopback link is a 
VLAN or top level ethernet or some type of P2P media. I have asked repeatedly 
of what use this information is and you have failed to provide any answer.

You also continue to promote the need to use an RFC 5316 like TLV to advertise 
the address of loopbacks – but again there is no need. The prefix associated 
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is 
associated with a loopback is identified by the presence of the N flag in the 
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback 
is identified by the RFC 7794 defined Router-ID sub-TLV(s).
[WAJ] Yes, You are right on the above information and I also know 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

No, as I indicated previously, this discussion has been had many times - it 
reminds me of 'Groundhog Day'.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, October 19, 2020 11:00 AM
> To: John E Drake 
> Cc: wang...@chinatelecom.cn; Peter Psenak ; Les
> Ginsberg (ginsberg) ; Christian Hopps
> ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Would you like to refer the cases raised from Robert?
> Such discussion can be fruitful for the refine or forwarding of this draft.
> One should convince others based on the fact, not subjective opinion.
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 19, 2020, at 22:52, John E Drake  wrote:
> >
> > Hi,
> >
> > It seems that we have been going around on this topic for an eternity, so to
> explain it again would simply be an exercise in pounding sand.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: wang...@chinatelecom.cn 
> >> Sent: Monday, October 19, 2020 10:41 AM
> >> To: John E Drake 
> >> Cc: Peter Psenak ; Peter Psenak
> >> ; Les Ginsberg (ginsberg) ;
> >> Christian Hopps ; Aijun Wang
> >> ; lsr- cha...@ietf.org; lsr@ietf.org; Jeff
> >> Tantsura ; draft-
> >> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Hi, John:
> >>
> >> Would you like to illustrate your broken case more clearly and not
> >> make the conclusion so hurry?
> >>
> >>
> >> Aijun Wang
> >> China Telecom
> >>
> >>> On Oct 19, 2020, at 22:15, John E Drake
> >>  wrote:
> >>>
> >>> Aijun,
> >>>
> >>> What part of "using IP address advertisement to derive topological
> >>> data is
> >> broken" do you not understand?
> >>>
> >>> Yours Irrespectively,
> >>>
> >>> John
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
> >>>> -Original Message-
> >>>> From: Peter Psenak 
> >>>> Sent: Monday, October 19, 2020 6:32 AM
> >>>> To: Aijun Wang ; Peter Psenak
> >>>> 
> >>>> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
> >>>> ; Christian Hopps ;
> >>>> John E Drake ; lsr-cha...@ietf.org;
> >>>> lsr@ietf.org; Jeff Tantsura ;
> >>>> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
> >>>> Subject: Re: [Lsr] WG Last Call
> >>>> draft-ietf-lsr-ospf-prefix-originator-06
> >>>> [External Email. Be cautious of content] Hi Aijun, please see inline:
> >>>>> On 19/10/2020 12:10, Aijun Wang wrote:
> >>>>> Hi. Peter, Les:
> >>>>> We have defined many extensions for protocol, but only a small
> >>>>> part of them
> >>>> are deployed. Have you ever considered the reason?
> >>>>> Adding more contents for their  potential usages can certainly be
> >>>>> helpful for
> >>>> their influences, or else, they will just stay at the IETF repository.
> >>>> I disagree. RFCs are not deployment or use case documents. They
> >>>> exists to address the interoperability.
> >>>>> More replies inline below.
> >>>>> Aijun Wang
> >>>>> China Telecom
> >>>>>> On Oct 19, 2020, at 17:14, Peter Psenak
> >>>>  wrote:
> >>>>>> Aijun,
> >>>>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >>>>>>> Aijun -
> >>>>>>> I am not going to continue these side discussions with you.
> >>>>>>> The primary purpose of the protocol extensions are as stated in
> >>>>>>> the draft
> >>>> Introduction. This is analogous to the use cases for the equivalent
> >>>> extensions for IS-IS already approved in RFC 7794. We need the
> >>>> equ

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Hi,

It seems that we have been going around on this topic for an eternity, so to 
explain it again would simply be an exercise in pounding sand.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: wang...@chinatelecom.cn 
> Sent: Monday, October 19, 2020 10:41 AM
> To: John E Drake 
> Cc: Peter Psenak ; Peter Psenak ;
> Les Ginsberg (ginsberg) ; Christian Hopps
> ; Aijun Wang ; lsr-
> cha...@ietf.org; lsr@ietf.org; Jeff Tantsura ; draft-
> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Hi, John:
> 
> Would you like to illustrate your broken case more clearly and not make the
> conclusion so hurry?
> 
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 19, 2020, at 22:15, John E Drake
>  wrote:
> >
> > Aijun,
> >
> > What part of "using IP address advertisement to derive topological data is
> broken" do you not understand?
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Peter Psenak 
> >> Sent: Monday, October 19, 2020 6:32 AM
> >> To: Aijun Wang ; Peter Psenak
> >> 
> >> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
> >> ; Christian Hopps ;
> >> John E Drake ; lsr-cha...@ietf.org; lsr@ietf.org;
> >> Jeff Tantsura ;
> >> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >> [External Email. Be cautious of content] Hi Aijun, please see inline:
> >>> On 19/10/2020 12:10, Aijun Wang wrote:
> >>> Hi. Peter, Les:
> >>> We have defined many extensions for protocol, but only a small part
> >>> of them
> >> are deployed. Have you ever considered the reason?
> >>> Adding more contents for their  potential usages can certainly be
> >>> helpful for
> >> their influences, or else, they will just stay at the IETF repository.
> >> I disagree. RFCs are not deployment or use case documents. They
> >> exists to address the interoperability.
> >>> More replies inline below.
> >>> Aijun Wang
> >>> China Telecom
> >>>> On Oct 19, 2020, at 17:14, Peter Psenak
> >>  wrote:
> >>>> Aijun,
> >>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >>>>> Aijun -
> >>>>> I am not going to continue these side discussions with you.
> >>>>> The primary purpose of the protocol extensions are as stated in
> >>>>> the draft
> >> Introduction. This is analogous to the use cases for the equivalent
> >> extensions for IS-IS already approved in RFC 7794. We need the equivalent 
> >> in
> OSPF.
> >>>>> You can show that you are listening to the concerns of WG members
> >>>>> by
> >> removing the Appendices - in which case you have (I believe) broad
> >> support for moving the draft forward.
> >>>> I agree with Les.
> >>>> As a co-author, I have asked you several times to get rid of the
> >>>> use case
> >> described in appendix.
> >>> [WAJ] Moving the expansion of this use case from body part of this
> >>> draft to its
> >> appendix is our initial consensus, not remove it totally. We have
> >> discussed intensely for its application in vary situations. The
> >> discussion results are stated clearly in the appendix.
> >> just because you insisted and did not listen to rest of us.
> >>> Wish to hear more technical analysis/comments for the current
> >>> statements of
> >> this part from other experts, or from you if you have fresh consideration.
> >> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
> >> myself) are telling you that using IP address advertisement to derive
> >> topological data is broken and you keep repeating it is valid use
> >> case and ask for more reasoning.
> >> thanks,
> >> Peter
> >>>> Trying to use prefix advertisement to derive topological data is
> >>>> simply
> >> broken. The reason we are adding the prefix originator extension to
> >> OSPF is NOT the broken use case in the appendix of the draft.
> >>>> thanks,
> >>>> Peter
> >>>>> 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Aijun,

What part of "using IP address advertisement to derive topological data is 
broken" do you not understand?

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Peter Psenak 
> Sent: Monday, October 19, 2020 6:32 AM
> To: Aijun Wang ; Peter Psenak
> 
> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
> ; Christian Hopps ; John E
> Drake ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Aijun,
> 
> please see inline:
> 
> 
> On 19/10/2020 12:10, Aijun Wang wrote:
> > Hi. Peter, Les:
> >
> > We have defined many extensions for protocol, but only a small part of them
> are deployed. Have you ever considered the reason?
> >
> > Adding more contents for their  potential usages can certainly be helpful 
> > for
> their influences, or else, they will just stay at the IETF repository.
> 
> I disagree. RFCs are not deployment or use case documents. They exists to
> address the interoperability.
> 
> >
> > More replies inline below.
> >
> >
> >
> > Aijun Wang
> > China Telecom
> >
> >> On Oct 19, 2020, at 17:14, Peter Psenak
>  wrote:
> >>
> >> Aijun,
> >>
> >>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >>> Aijun -
> >>> I am not going to continue these side discussions with you.
> >>> The primary purpose of the protocol extensions are as stated in the draft
> Introduction. This is analogous to the use cases for the equivalent 
> extensions for
> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> >>> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support for
> moving the draft forward.
> >>
> >> I agree with Les.
> >>
> >> As a co-author, I have asked you several times to get rid of the use case
> described in appendix.
> > [WAJ] Moving the expansion of this use case from body part of this draft to 
> > its
> appendix is our initial consensus, not remove it totally. We have discussed
> intensely for its application in vary situations. The discussion results are 
> stated
> clearly in the appendix.
> 
> just because you insisted and did not listen to rest of us.
> 
> > Wish to hear more technical analysis/comments for the current statements of
> this part from other experts, or from you if you have fresh consideration.
> 
> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
> myself) are telling you that using IP address advertisement to derive 
> topological
> data is broken and you keep repeating it is valid use case and ask for more
> reasoning.
> 
> thanks,
> Peter
> 
> >
> >> Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is 
> NOT
> the broken use case in the appendix of the draft.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>> You can then write a separate draft to discuss other use cases and allow 
> >>> the
> WG to discuss those other use cases w/o preventing the extensions from being
> approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >>> If you remove the Appendices I can support the draft.
> >>> If you do not remove the Appendices I cannot support the draft.
> >>> Please discuss this with your co-authors and come to consensus on your
> next step.
> >>> Les
> >>>> -Original Message-
> >>>> From: Aijun Wang 
> >>>> Sent: Monday, October 19, 2020 12:06 AM
> >>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> >>>> 
> >>>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> >>>> lsr@ietf.org; 'Jeff Tantsura' ;
> >>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> >>>> Subject: RE: [Lsr] WG Last Call
> >>>> draft-ietf-lsr-ospf-prefix-originator-06
> >>>>
> >>>> Hi, Les:
> >>>>
> >>>> As I stated clearly before, the appendix described in the draft is
> >>>> not the new use case. It is the start point of this draft.
> >>>> Have you noticed that the intro

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

I agree w/ Les, who I think has been extremely reasonable throughout this 
discussion.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, October 19, 2020 3:32 AM
> To: Aijun Wang ; 'Christian Hopps'
> 
> Cc: John E Drake ; lsr-cha...@ietf.org; lsr@ietf.org; 
> 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Aijun -
> 
> I am not going to continue these side discussions with you.
> 
> The primary purpose of the protocol extensions are as stated in the draft
> Introduction. This is analogous to the use cases for the equivalent 
> extensions for
> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> 
> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support for
> moving the draft forward.
> You can then write a separate draft to discuss other use cases and allow the 
> WG
> to discuss those other use cases w/o preventing the extensions from being
> approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> 
> If you remove the Appendices I can support the draft.
> If you do not remove the Appendices I cannot support the draft.
> 
> Please discuss this with your co-authors and come to consensus on your next
> step.
> 
>Les
> 
> 
> > -Original Message-
> > From: Aijun Wang 
> > Sent: Monday, October 19, 2020 12:06 AM
> > To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> > 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: RE: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Hi, Les:
> >
> > As I stated clearly before, the appendix described in the draft is not
> > the new use case. It is the start point of this draft.
> > Have you noticed that the introduction part is not the final usage of
> > such protocol extension information?
> > Certainly, we will not expand all the possible use cases in very
> > detail, but putting some of them(some interesting, prominent use
> > cases) in the appendix will not hamper the protocol extension itself.
> >
> > If the statements/descriptions in the appendix are not correct, we can
> > fix it, or remove it finally.  If not, why not let it be for reference
> > to the user of such protocol extension?
> > For the body part of this draft, we are also welcome comments.
> >
> > More replies inline below[WAJ]
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -Original Message-
> > From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> > Les Ginsberg (ginsberg)
> > Sent: Monday, October 19, 2020 2:15 PM
> > To: Aijun Wang ; 'Christian Hopps'
> > 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> > Ginsberg (ginsberg)' ;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Aijun -
> >
> > The "use case" for the protocol extensions is clearly stated in the
> > Introduction:
> >
> > "The primary use case for the extensions proposed in this document is
> >to be able to identify the originator of the prefix in the network.
> >In cases where multiple prefixes are advertised by a given router, it
> >is also useful to be able to associate all these prefixes with a
> >single router even when prefixes are advertised outside of the area
> >in which they originated.  It also helps to determine when the same
> >prefix is being originated by multiple routers across areas."
> >
> > This is equivalent to language in RFC 7794 which defines the analogous
> > extensions for IS-IS.
> >
> > Everything you have in the Appendix is not related to the primary use
> > case - and is fact a use case which many of us have objected to.
> > [WAJ] Very glad to know the false statements in the appendix.
> >
> > You are entitled to write another draft advocating for your new use
> > case if you wish, but requiring that the protocol extensions in
> > support of the primary use case not go forward without your new use
>

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Hi,

I agree with Les.  This is a simple protocol extension for a specific purpose 
and there is no reason to include speculation about its use for other purposes, 
particularly when it is inherently not suited for them.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, October 15, 2020 12:33 PM
> To: Christian Hopps ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> I support moving this document forward.
> Similar functionality in IS-IS has proved useful.
> 
> I would however like to repeat comments I made earlier in the review of this
> document.
> The content of the Appendices should be removed.
> The Appendices define and discuss deriving topology information from prefix
> advertisements - which is flawed and should not be done.
> Perhaps more relevant, the purpose of the document is to define  protocol
> extensions supporting advertisement of the originators of a prefix
> advertisement. There is no need to discuss how this mechanism might be used to
> build topology information.
> This document should confine itself to defining the protocol extensions - 
> similar
> the RFC 7794.
> 
> If the authors do not agree to do this, I would encourage this point to be
> discussed during IESG review.
> 
>Les
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Christian Hopps
> > Sent: Wednesday, October 14, 2020 11:15 PM
> > To: lsr@ietf.org
> > Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
> > lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps
> > 
> > Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> >
> > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> >
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK
> > 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
> >
> > The following IPR has been filed
> > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
> > !NEt6yMaO-
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
> > 5KtUHQ$
> >
> > Authors,
> >
> >   Please indicate to the list, your knowledge of any other IPR related
> > to this work.
> >
> > Thanks,
> > Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
> Lc$

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

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

[John E Drake]

Hi,

The proponents of this draft seem to be arguing by repeated assertion.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Kiran Makhijani
Sent: Thursday, September 3, 2020 5:07 PM
To: Gyan Mishra ; Robert Raszuk 
Cc: Les Ginsberg ; tony...@tony.li; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; Gengxuesong (Geng Xuesong) 
; Huaimo Chen 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

[External Email. Be cautious of content]

Yup, that can be done. But I see steps such as ATT configuration as an 
additional effort when splitting areas. With TTZ, this propagation is not 
needed. Given that an operator has chosen to split the area anyway, TTZ process 
and config steps are relatively simple explained earlier 
(https://mailarchive.ietf.org/arch/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/).
-Kiran

From: Lsr  On Behalf Of Gyan Mishra
Sent: Wednesday, September 2, 2020 6:29 AM
To: Robert Raszuk 
Cc: Les Ginsberg ; tony...@tony.li; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; Gengxuesong (Geng Xuesong) 
; Huaimo Chen 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Since careful planning and design is required to split a L1 Area into L1a L1b 
using TTZ as this is a major effort to plan out.  It maybe easier as part of 
the planning effort to just create two separate L1 areas that have different 
L1/L2 attachment points for the attach bit to be propagated.  Use existing ISIS 
machinery to now create two new smaller L1 areas.

Kind Regards

Gyan

On Wed, Sep 2, 2020 at 5:04 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

>  acknowledged problem (IGP scalability)

Great so we see the problem description. This is progress !

Allow me to observe two points:

* IGP scalability can be easily solved with the additional levels of current 
abstraction instead of introducing new types of abstraction into it. Ref: 
draft-ietf-lsr-isis-extended-hierarchy

* Most scaling aspects I have seen in practical deployments with IGPs are not 
caused by the suboptimal protocol design. Those are caused by requirements 
introduced by some transport technologies which (at least originally) required 
flooding of host routes domain wide for exact match of FECs to prefixes. I do 
not see how TTZs would address that aspect in any better way than areas can.

Thx,
R.


On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>> wrote:











Hi Tony,



My intension was not to talk about math/engineering/marketing or compare the 
size of marketing

department. Them are not relevant to this thread.

I want to make clear about IETF process. In my understanding the document does 
not need to be

perfect at this stage, as long as it is in the right direction to solve some 
acknowledged problem( IGP scalability). Comments will be helpful if it could 
provide ideas about how to improve.

But IMO the discussion in the mailing list about this draft has gone off the 
rails of technology,

including keeping challenging tradeoff between value and complexity, which 
seems reasonable at the first sight, but at this stage, has turned out to be a 
question with no right answer and may bring endless argument.





Thanks

Xuesong





From: Tony Li [mailto:tony1ath...@gmail.com]

On Behalf Of tony...@tony.li


Sent: Wednesday, September 2, 2020 12:07 PM


To: Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>


Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Les 
Ginsberg mailto:ginsb...@cisco.com>>; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org


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









Hi Xuesong,










Apologies first if I have missed any history of this discussion. But I'm not 
sure that we have to evaluate whether a method

is "optimal" before WG adoption. Why not adopt some alternative solutions and 
leave the choice to industry/market?












First off, this is engineering, not theoretical math.  Optimal is not the 
issue. Heck, optimal isn't even a goal.








What we are looking for is value and value that outweighs the complexity.







Leaving the choice to the market is a bad idea. The market does NOT make sound 
technical decisions. It makes pseudo-random decisions not based on technical 
merits. The canonical example here is VHS vs Betamax. Better

technology lost.







Second, the market is unduly influenced by marketing. The size of your 
marketing department exceeds the size of my 

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

[John E Drake]

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" - 
draft-chen-isis-ttz-11.txt

[External Email. Be cautious of content]

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 characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.

I am therefore opposed to WG adoption of TTZ.

   Les



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 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 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 differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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

Re: [Lsr] Request WG adoption of TTZ

[John E Drake]

I agree w/ Henk.  The TTZ seems to be a gratuitous addition.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Henk Smit
> Sent: Wednesday, July 15, 2020 8:22 AM
> To: Huaimo Chen 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> [External Email. Be cautious of content]
> 
> 
> Huaimo Chen wrote on 2020-07-14 06:09:
> 
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
> 
> I don't agree that this convenience is really beneficial.
> I actually think this convenience is a downside.
> 
> 
> Link-state protocols are not easy to understand. And we already have the
> misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the concept of an
> area makes things only more complex.
> 
> How often will this new flexibility be used in the real world ?
> I still haven't seen an answer to Christian Hopp's simple question:
> "Has RFC8099 been deployed by anyone ?"
> Anyone who has an answer ?
> 
> My favorite rule of RFC1925 is rule 12:
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
> 
> Adding a new concept, with very little benefit, hurts the protocol in the 
> long run.
> The ability to abstract an area, and not also a zone, is strong enough to be
> worthwhile, imho.
> 
> henk.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!Qd22Qan7jubM_Vup5P5G6gsGg_horPl4PSDx8qS_v03ZIb8sNalgwEsGJ7Q61cc
> $

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

[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] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[John E Drake]

Aijun,

Any network slicing proposal is going to require active management of the 
underlay network in response to changes in the requirements of the overlay 
VPNs.  The text you quote is designed to address a different issue which none 
of the other network slicing proposals address, viz, in a heterogeneous mix of 
regular and enhanced VPNs, how do you ensure that regular VPNs, that know 
nothing about the enhanced VPNs, don’t use the resources that are supposed to 
be used only by enhanced VPNs?  See also:  
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-07.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Thursday, March 26, 2020 9:37 PM
To: John E Drake 
Cc: Joel M. Halpern ; xie...@chinatelecom.cn; lsr 

Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

[External Email. Be cautious of content]

Hi, John:
In your proposal, there is the following text “ the network controller SHOULD 
ensure that the IGP and TE metrics for these resources is higher than the 
metrics for the underlay network resources allocated to non-enhanced VPNs.”
Considering these resources will span across the network and be changed upon 
the slicing requirements , will such arrangement make the metric allocation 
within the network a mess?
If the above statement can’t be met, how you ensure the traffic that pass the P 
router use the dedicated resource(for example, bandwidth)?
Aijun Wang
China Telecom

On Mar 26, 2020, at 23:31, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:
Hi,

As Joel notes, it is true that enhanced VPNs require the use of specific 
underlay network resources, either dedicated or shared, but the this needs to 
be done without installing overlay VPN awareness in the P routers, which is 
inherently unscalable and operationally complex.  Also, since VPNs span 
multiple ASes, putting overlay VPN state in an IGP doesn't work.

Please see:  https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-02

Yours Irrespectively,

John


Juniper Business Use Only

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Joel 
M. Halpern
Sent: Thursday, March 26, 2020 9:36 AM
To: xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
Virtual Transport Network

[External Email. Be cautious of content]


In once sense, the statement is inherently true.  A VPN technology without
underlay support would seem to have significant difficulty in consistently
meeting an SLA.  Having said that much, the rest does not seem to follow.

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

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[John E Drake]

Hi,

As Joel notes, it is true that enhanced VPNs require the use of specific 
underlay network resources, either dedicated or shared, but the this needs to 
be done without installing overlay VPN awareness in the P routers, which is 
inherently unscalable and operationally complex.  Also, since VPNs span 
multiple ASes, putting overlay VPN state in an IGP doesn't work. 

Please see:  https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-02

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Joel M. Halpern
> Sent: Thursday, March 26, 2020 9:36 AM
> To: xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> [External Email. Be cautious of content]
> 
> 
> In once sense, the statement is inherently true.  A VPN technology without
> underlay support would seem to have significant difficulty in consistently
> meeting an SLA.  Having said that much, the rest does not seem to follow.
> 
> Yours,
> Joel
> 
> On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote:
> >
> > Hi, Joel,
> >
> > The statement is that pure overlay VPNs cannot meet the requirement of
> > some new services, and it would require integration between the
> > underlay and the overlay networks.
> >
> > As mentioned in this document, there is existing technology in the
> > underlay to support enhanced VPNs , such as using a set of MPLS-TE
> > based resource reserved point-to-point paths, while it scalability is
> > the concern of many operators.
> >
> > Thus VTN is introduced to provide the required topology and resource
> > attribute in the underlay in a scalable manner. This is described in
> > the introduction section.
> >
> > Hope this helps.
> >
> >
> > Chongfeng
> >
> >
> > *From:* Joel M. Halpern 
> > *Date:* 2020-03-25 21:52
> > *To:* xie...@chinatelecom.cn ; lsr
> > 
> > *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
> > Routing based Virtual Transport Network
> > This drafts starts by asserting that there are limitations on what can
> > be done with the existing technology.  As the description is quite
> > vague, I can not be certain.  But I do not know of any difficulty in
> > providing the described capabilities with current technology, without
> > introducing a new, undescribed, construct called a VTN.
> > Yours,
> > Joel
> > On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:
> >  >
> >  > Hello, folks,
> >  >
> >  > we have submitted a new draft of
> >  >   
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xie-lsr-
> isis-sr-vtn-mt-00__;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyXyHvpt8$  .
> >  >
> >  > It is about Using IS-IS Multi-Topology (MT) for Segment Routing
> > based
> >  > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> >  > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> >  > support some applications's needs of enhanced isolation and
> > stringent
> >  > performance requirements.  VPN+ requries integration between the
> > overlay
> >  > VPN and the underlay network.  A Virtual Transport Network (VTN)
> > is a
> >  > virtual network which consists of a subset of the network toplogy
> > and
> >  > network resources allocated from the underlay network.  A VTN
> > could be
> >  > used as the underlay for one or a group of VPN+ services.. This
> > document
> >  > describes a simplified mechanism to build the SR based VTNs using
> > IGP
> >  > multi- topology together with other well-defined IS-IS extensions.
> >  >
> >  > Comments and suggestions are highly appreciated.
> >  >
> >  > Chongfeng Xie
> >  >
> >  >
> >  >
> >  > ___
> >  > Lsr mailing list
> >  > Lsr@ietf.org
> >  >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$
> >  >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 

Re: [Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt

[John E Drake]

I'm not aware of any IPR.

Yours Irrespectively,

John



Juniper Internal
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, April 10, 2019 5:30 PM
To: draft-ietf-isis-te-...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] IPR Poll for "IS-IS TE Attributes per application" - 
draft-ietf-isis-te-app-06.txt

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] Open issues with Dynamic Flooding

[John E Drake]

Hi,

What does 'rate limit' mean in this context?

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, March 7, 2019 2:20 PM
> To: tony...@tony.li
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Open issues with Dynamic Flooding
> 
> On 07/03/2019 18:16 , tony...@tony.li wrote:
> >
> >
> >> On Mar 5, 2019, at 1:31 PM, tony...@tony.li 
> >> wrote:
> >>
> >> Let me propose that we add something to sections 6.7.5, 6.7.9, and
> >> 6.7.11 like:
> >>
> >> Addition of temporary flooding should be done with caution, as the
> >> addition of excessive connectivity to the flooding topology may
> >> trigger unwanted behavior. Routers SHOULD add temporary flooding in a
> >> rate limited manner, if not configured otherwise.
> >
> >
> > Hi,
> >
> > I haven’t heard any feedback on this.  Can we please adopt this?
> >
> > The draft cutoff is Monday, March 11.  Could we please incorporate
> > this change and the addition of the pseudonode identifier by then?
> 
> I don't think there is an agreement on the LAN side.
> 
> Rate limiting we can add, but we can do that after March 11, I don't see a 
> need
> to do it before.
> 
> thanks,
> Peter
> 
> 
> >
> > Tony
> >
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lsr=DwIGaQ=HAkYuh63rsuhr6Scbfh0
> UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=8bZHYmmMERie3AZxsYrvUH_fhv9JyTIkivlY1wizKms
> =ZRx3I9aH56q-UmcY_tUkOuIAxjGDEMgE_qeMPmekSgk=
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Open issues with Dynamic Flooding

[John E Drake]

I agree w/ Peter.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Tuesday, March 5, 2019 2:38 AM
> To: tony...@tony.li; lsr@ietf.org
> Subject: Re: [Lsr] Open issues with Dynamic Flooding
> 
> Hi Tony,
> 
> On 04/03/2019 18:54 , tony...@tony.li wrote:
> >
> > Hello,
> >
> > There are still two issues that need to be discussed and I was hoping that 
> > we
> could make progress on the mailing list before Prague.
> >
> > 1) Temporary additions to the flooding topology
> >
> > There are several cases where we would like to make temporary additions
> to the flooding topology: repairing a partition of the flooding topology or
> adding a node to the base topology for the first time. We can:
> >
> > (a) Temporarily add all of the links that would appear to remedy the
> partition. This has the advantage that it is very likely to heal the 
> partition and will
> do so in the minimal amount of convergence time.
> >
> > (b) For each node adjacent to the partition, add no more than a single 
> > link
> across the partition.  If that does not repair the partition in a while (LSP
> propagation time + SPF time), then add another link.
> >  Iterate as necessary. This has the advantage that it minimizes the 
> > risk of
> creating a cascade failure.
> 
> I prefer (a) because of the faster convergence.
> Adding all links on a single node to the flooding topology is not going to 
> cause
> issues to flooding IMHO.
> 
> >
> > 2) Inclusion of pseduonodes in the System IDs TLV
> >
> > In the general case, a topology can include LANs. If a LAN is in 
> > parallel with a
> P2P link, the Area Leader cannot currently distinguish between the two links.
> This can be of importance if there are other
> > systems also on the LAN that should be using their LAN interface for
> flooding.
> >
> > We propose to change the System IDs TLV to include a pseudo-node ID as
> well as the system ID.  It would also make sense to rename the TLV to be the
> “IS-IS Area Node IDs TLV”.
> >
> > Behaviorally, we should add a requirement that if the Area Leader 
> > includes a
> pseudonode in the flooding topology, then all systems with an adjacency on 
> that
> LAN should use the LAN as part of the
> > flooding topology, whether or not they are explicitly listed as 
> > adjacent to
> the LAN in the Flooding Path TLV.
> 
> given that the flooding on the LAN in both OSPF and ISIS is done as multicast,
> there is currently no way to enable flooding, either permanent or temporary,
> towards a subset of the neighbors on the LAN. So if the flooding is enabled 
> on a
> LAN it is done towards all routers connected to the it.
> 
> Given that all links between routers are p2p these days, I would vote for
> simplicity and make the LAN always part of the FT.
> 
> thanks,
> Peter
> 
> 
> 
> >
> > Thoughts? Comments? Flames?
> >
> > Regards,
> > Tony
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_lsr=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoC
> > I=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=-
> E417ANRfgLCiCgXawxe
> > jcJyxNXCOHzVoAMRCQET2qU=LRWmU6Ra23ZzfiJF-
> sz0YFSTvQX5bU5qdQk5BKdhCX0&
> > e=
> >
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lsr=DwIGaQ=HAkYuh63rsuhr6Scbfh0
> UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=-
> E417ANRfgLCiCgXawxejcJyxNXCOHzVoAMRCQET2qU=LRWmU6Ra23ZzfiJF-
> sz0YFSTvQX5bU5qdQk5BKdhCX0=
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[John E Drake]

Chris,

Well put.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Thursday, February 14, 2019 10:56 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; 'Christian Hopps'
> ; Aijun Wang 
> Subject: Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 +
> IPR poll.
> 
> 
> Hi folks,
> 
> It's not useful for people to be adding a bunch of extra qualifications and
> caveats to the adoption poll.
> 
> This is not a dual adoption poll. We are not calling for adoption of an 
> unwritten,
> unfinished algorithm document. That makes no sense; we adopt reviewed
> acceptable work, not the promise of it. We're also not going to hold up
> standardizing the signaling work waiting on unfinished algorithm work, that's
> literally the opposite of the goal here which is to un-tie these two things 
> so we
> can make progress on both in parallel.
> 
> Thanks,
> Chris.
> 
> Aijun Wang  writes:
> 
> > Hi, Christian:
> >
> > Supports for the adoption of two drafts at the same time, in which
> > one(draft-li-lsr-dynamic-flooding-02) focuses on the centralized mode
> > and the other(draft-cc-lsr-flooding-reduction-01) focuses on the
> > distributed mode.
> >
> > The centralized mode for is one straightforward way to realize the
> > flooding reduction, and I admire Tony Li give his solution first. But
> > from the consideration of solution robustness, the distributed mode
> > may be more promising.
> > My consideration for distributed mode is that it should not cover only
> > the algorithm, more contents need to be standardized in future. Huaimo
> > has one good start point for distributed mode, and he also gives
> > abundant thoughts for the centralized mode that the current version of
> > draft-li-lsr-dynamic-flooding-02 has not covered yet.
> >
> > Proposal for the name of two drafts may be
> > draft-ietf-lsr-flooding-reduction-centralized-mode and
> > draft-ietf-lsr-flooding-reduction-distributed-mode.
> >
> >
> > Best Regards.
> >
> > Aijun Wang
> > Network R and Operation Support Department China Telecom Corporation
> > Limited Beijing Research Institute,Beijing, China.
> >
> > -邮件原件-
> > 发件人: Christian Hopps [mailto:cho...@chopps.org]
> > 发送时间: 2019年2月11日 18:45
> > 收件人: lsr@ietf.org
> > 抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> > 主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
> > poll.
> >
> >
> > Hi Folks,
> >
> > We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
> >
> > The aim of this document is to describe the problem space and
> > standardize a way to signal dynamic flooding information. It does not
> > standardize any specific algorithm for flooding topology creation.
> >
> > Authors please respond indicating if you are aware of any IPR related
> > to this work.
> >
> > We also have another draft (draft-cc-lsr-flooding-reduction-01) that
> > started as a distributed flooding topology algorithm and morphed into
> > that plus competing ideas on signaling of flooding topology
> > information. The intent after adoption of
> > draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can discuss
> > adding any signaling ideas from this work to the adopted signaling
> > draft (with proper attribution given as appropriate), and two, for the
> > authors of draft-cc-lsr-flooding-reduction-01 to publish a new
> > document without the signaling portion and instead focus on their
> > flooding topology algorithm. This new focused document can be considered in
> parallel along with the other algorithm work that has been proposed.
> >
> > Flooding topology creation is seen as a hard problem for which we
> > don't expect a one-size-fits-all solution. Taking the steps outlined
> > above will help us move forward on the solutions.
> >
> > Thanks,
> > Chris & Acee.
> > LSR WG Chairs.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[John E Drake]

Hi,

I completely agree with Peter.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, February 14, 2019 2:30 AM
> To: Huaimo Chen ; Acee Lindem (acee)
> ; Christian Hopps ; lsr@ietf.org
> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> Hi Huaimo,
> 
> On 13/02/2019 22:50 , Huaimo Chen wrote:
> > Hi Peter,
> >
> > My explanations/answers are in line below with prefix [HC].
> >
> > -Original Message-
> > From: Peter Psenak [mailto:ppse...@cisco.com]
> > Sent: Wednesday, February 6, 2019 4:58 AM
> > To: Huaimo Chen ; Acee Lindem (acee)
> > ; Christian Hopps ; lsr@ietf.org
> > Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> >
> > Hi Huaimo,
> >
> > On 03/02/2019 17:58 , Huaimo Chen wrote:
> >> Hi Acee,
> >>
> >>
> >>
> >> I agree with you on keeping the signaling for two modes. The
> >> other parts for the distributed solution need to be removed.
> 
> optimized flooding is not only about algorithm to calculate the flooding
> topology and the way it is distributed/computed. It is also about local rules 
> to
> make sure the flooding remains consistent. These are _independent_ of
> centralized/distributed modes. And it make no sense to specify these rules in
> two drafts.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described in 
> > draft-
> li-dynamic-flooding. For example, there are a few of places from page 27 to 
> 30,
> which define the behaviors specific for the distributed solution/mode.
> 
> I strongly disagree. The fact that we say in centralized mode area leader
> recomputes and in distributed mode all nodes recompute make no difference in
> behavior.
> 
> thanks,
> Peter
> 
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2. distribution of 
> > the
> flooding-topology, which is specific to centralized mode 3. common behavior of
> the nodes that support the extension, which is independent of the mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more,
> including concrete protections, operations, and algorithms for computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
> > thanks,
> > Peter
> >
> >
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Huaimo,
> >>
> >>
> >>
> >> See inline.
> >>
> >>
> >>
> >> *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> >> behalf of Huaimo Chen  >> >
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "lsr@ietf.org "  >> >
> >> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Everyone,
> >>
> >>
> >>
> >> We proposed the distributed solution first, and Tony proposed the
> >> centralized solution first. Tony added the distributed solution
> >> (except for the algorithms to compute flooding topology) into his
> >> draft. And then we added the centralized solution into our draft. The
> >> latest versions of the two drafts have largely converged at least at
> >> the high level to a solution for solving the same problem.
> >>
> >>
> >>
> >> Our draft has multiple key technical advantages over Tony's draft as
> >> we described in our email to the LSR list, which are summarized below:
> >>
> >> 1.   It uses a fraction of flooding resource (i.e., it is multiple
> >> times more efficient in flooding topology encoding);
> >>
> >> 2.   It provides fault tolerance to multiple failures, minimizing
> >> impact on network convergence, thus minimizing traffic lose; and
> >>
> >> 3.   It is simpler and needs less processing time (i.e., faster and
> >> more efficient) in multiple scenarios.
> >>
> >> Based on the technical merits, our draft should be moved forward.
> >> However, Chair proposed to move Tony's draft forward and have us work
> >> on a distributed algorithm as we started with.
> >>
> >>
> >>
> >> I think that the distributed solution in Tony's draft needs to be
> >> removed and they work on the centralized solution. We remove the
> >> centralized solution from our draft and work on the distributed solution.
> >>
> >>
> >>
> >> I'm against "cutting the baby in half" given that the signaling for
> >> the distributed solution is a proper subset of what is required for
> >> the centralized solution. It is undesirable to have different
> >> signaling for the two modes. For the distributed algorithm you are
> >> proposing, do see problems with the signaling?
> >>
> >>
> >>

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[John E Drake]

Chris & Acee,

This looks fine to me.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Friday, February 1, 2019 7:26 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> 
> Summary of where we are at with dynamic flooding reduction:
> 
>  - We have a well written original work that came first and described the
> problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-
> flooding). We do not need to standardize the centralized algorithm.
> 
>  - A small change to this work allowed for distributed algorithms and for 
> outside
> work on distributed algorithms to continue in parallel.
> 
>  - We have another original work that started primarily as a distributed 
> algorithm
>(draft-cc-ospf-flooding-reduction)
> 
>  - Finally we also have:
>- Cross-pollination of ideas.
>- Failed attempts at merging.
>- An authors list "Arms-Race".
> 
> Moving forward:
> 
> - During IETF 103 I proposed we have no conflict if we:
> 
>1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
> algorithm as they started with.
> 
> - Acee agreed during the meeting (as chair) that this was the best way 
> forward.
> We had some agreement form the floor as well.
> 
> - Any good ideas regarding the distribution of a centralized topology can be
> debated and added (with appropriate attribution) to the base document after we
> adopt one.
> 
> - This is what happens when we adopt a document as WG work, we work on it.
> 
> - The original authors of the distributed solution can continue to work on 
> their
> distributed algorithm in a separate document which would also need
> standardization.
> 
> Does anyone see a serious problem with this path forward?
> 
> Thanks,
> Chris & Acee.
> LSR Chairs.
> 
> Christian Hopps  writes:
> 
> > We've had the authors of the individual conflicting drafts take a shot at
> merging their work.
> >
> >This has failed.
> >
> > Here is the full history (which I also summarized during IETF103 as well). 
> > I will
> send a second email discussing this.
> >
> > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-
> flooding-isis
> >   published centralized solution.
> >
> > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> > draft-cc-ospf-
> flooding-reduction
> >   published distributed solution.
> >   - mention of centralized solution asserting it is not good choice.
> >
> > - IETF 101 (Mar 2018)
> >   - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-
> 6ZTP5j_HaBNdfPbgxGIp22cnaWS
> >   - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-
> lsr-00
> >   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
> > - Generally well received.
> >   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
> > - Serious problems immediately found during presentation -- not fully 
> > baked.
> >
> > - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
> > - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
> > - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
> > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
> >   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
> >   - Does not specify distributed algorithm only how to indicate one in use, 
> > small
> change.
> >
> > - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
> >
> > - IETF 102 (Jul 14, 2018)
> >   - draft-li-dynamic-flooding-05 presented.
> >   - draft-cc-ospf-flooding-reduction-02 presented.
> >
> > - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
> >   - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
> >
> > - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
> >
> > - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
> >
> > - IETF 103 (Nov 3, 2018)
> >
> >   - Chairs give direction
> >
> > - draft-li-lsr-dynamic-flooding-05 having come first, being well 
> > written and
> not
> >   specifying a distributed algorithm (merely allowing for one) is the 
> > correct
> vehicle
> >   to adopt as a base document.
> >
> > - Distributed algorithm work (the original basis for 
> > draft-cc-ospf-flooding-
> reduction)
> >   should continue as a separate document form the base which would thus
> we have no
> >   conflicts.
> >
> > - In the meantime the authors try and merge work, this fails.
> >
> > - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
> >
> > - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
> >
> > - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)

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

Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

[John E Drake]

Hi,

The answers that Les gives, below, to Yoshifumi are completely correct.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) 
Sent: Friday, December 7, 2018 3:06 PM
To: Yoshifumi Nishida 
Cc: nish...@wide.ad.jp; tsv-...@ietf.org; lsr@ietf.org; i...@ietf.org; 
draft-ietf-lsr-isis-rfc7810bis@ietf.org
Subject: RE: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Yoshi –

I’ll try to provide some response to your comments. I preface this by saying:

1)I was not an author on RFC 7810. It is possible that my remarks do not 
accurately reflect the thinking of the original authors. If so, I hope one or 
more of them will find the time to correct me.

2)The intent of this bis draft was solely to correct the editorial issue which 
resulted in confusion and interoperability issues associated with the sub-TLV 
encoding for the three bandwidth TLVs. There are implementations based on RFC 
7810 and no one to my knowledge has expressed confusion regarding how to take 
the measurements – nor has anyone expressed concern as to any omissions in the 
parameters advertised. Therefore we have no reason to alter the existing text 
in these areas.

Responses inline.

From: Yoshifumi Nishida mailto:nish...@sfc.wide.ad.jp>>
Sent: Thursday, December 06, 2018 1:31 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: nish...@wide.ad.jp; 
tsv-...@ietf.org; lsr@ietf.org; 
i...@ietf.org; 
draft-ietf-lsr-isis-rfc7810bis@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Hi Les,

On Wed, Dec 5, 2018 at 4:51 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Yoshi -

Thanx for taking the time to review.

I can appreciate that this may the first time you have looked at RFC7810 - let 
alone the bis draft. As a result you have commented on content which is common 
to the bis draft and the RFC it is modifying (RFC 7810).

While your questions in isolation may be interesting, I believe they are out of 
scope for the review of the bis draft. What the bis draft is doing is 
addressing two modest errata - details of which can be found in 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A
Comments on content not related to those changes is out of scope.

Just to be clear, my comments on this draft were clarification questions which 
won't request changes in the spec of the draft because I thought there are a 
certain ambiguities in the draft.
But, if what you really mean is there is no ambiguities or confusions among 
expected readers on the points I made, it makes a sense to me and I can think I 
had unnecessary concerns.
However, I'm not fully sure about it yet.

For example, the draft mentions about delay variation and it seems to me this 
term is a bit ambiguous. If expected readers can understand it means (for 
example) mean deviation, I am fine with it.
But, in this case,I might want to see supportive comments on this view from the 
community.
Or, if you can clarify that even if there are some discrepancies between 
implementations it won't affect overall performance of the applications,  I am 
also fine with it.

Anyway, I just tried to do my best to read and review the draft. I hope not, 
but if the points I made don't make sense please let me know.
I would like to leave further decisions to ADs.

If you have an interest in this topic and want to comment on the substance of 
RFC 7810 and its companion document for OSPF RFC 7471, I encourage you to do 
so. Note that all of your comments (save the one on Security) are also 
applicable to RFC 7471 - so any agreed upon modification would need to be made 
to both documents. But I do not want to even start discussing such changes in 
the context of reviewing the bis draft changes. I hope you can understand why.

As regards your Security comment, I am not sure I understand what you are 
suggesting. As IGP info is flooded hop-by-hop, man-in-the-middle attacks have 
to be able to insert themselves on an IGP enabled link. Use of cryptographic 
authentication prevents untrusted sources from being accepted - which is the 
point being made.

As Spencer already made my point clear (Thanks Spencer!), I was wondering if we 
need a normative language here as the draft mentions these info can be 
sensitive.
I was also wondering why the draft didn't mention encryption while it conveys 
sensitive info.

[Les:] IS-IS runs directly over Layer 2 and does not support encryption.

Thanks,
--
Yoshi



> -Original Message-
> From: Yoshifumi 

Re: [Lsr] [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[John E Drake]

Alvaro,

As I said, John’s suggestion is correct and it does match 7471, which is also 
correct.

Yours Irrespectively,

John

From: Idr  On Behalf Of Alvaro Retana
Sent: Wednesday, November 28, 2018 5:16 PM
To: John Scudder 
Cc: lsr@ietf.org; idr-cha...@ietf.org; draft-ietf-idr-te-pm-...@ietf.org; Hares 
Susan ; idr@ietf. org 
Subject: Re: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now reads:

   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 
4.5)
 minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link residual bandwidths (see Section 
4.5)
 minus the sum of the

   measured bandwidth used for the actual forwarding of non-RSVP-TE

   label switched path packets on all component links.
This version gets rid of the duplication and uses “residual”.  Because it’s 
been through WGLC I am assuming it is correct.  If not, please let me know 
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02


On November 28, 2018 at 4:33:54 PM, John Scudder 
(j...@juniper.net) wrote:
+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address this report [1].  Instead of trying 
to fix the definition here, I think that a similar report should be filed 
against rfc7471.  Please submit it and I will approve.

[1] 
https://www.rfc-editor.org/errata/eid5486

Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810 
paragraph in question:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

It seems obvious that there was a cut-and-paste problem or similar, since the 
same sentence is duplicated with minor changes. But the erratum leaves the 
duplication! The erratum wants it to be:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link (residual) bandwidths minus the measured 

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[John E Drake]

Hi,

Comments inline

Yours Irrespectively,

John

From: Idr  On Behalf Of John Scudder
Sent: Wednesday, November 28, 2018 4:34 PM
To: Alvaro Retana 
Cc: lsr@ietf.org; idr@ietf. org ; 
draft-ietf-idr-te-pm-...@ietf.org; Hares Susan ; 
idr-cha...@ietf.org
Subject: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address this report [1].  Instead of trying 
to fix the definition here, I think that a similar report should be filed 
against rfc7471.  Please submit it and I will approve.

[1] 
https://www.rfc-editor.org/errata/eid5486

Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810 
paragraph in question:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

It seems obvious that there was a cut-and-paste problem or similar, since the 
same sentence is duplicated with minor changes. But the erratum leaves the 
duplication! The erratum wants it to be:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link (residual) bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

So the proposed "fix" is to leave the sentence duplicated, but change 
"available" to "(residual)" in the first copy? I don't think that could 
possibly be right. Just eyeballing it, it seems to me as though the correct fix 
would be to change the paragraph to be:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.



[JD]  John's suggestion, above, is correct.

in which case it would match RFC 7471. Or possibly:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available residual bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

I have no idea which of these is right, but the erratum can't be right. 
Naively, they look 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

There is no virtually no difference between the two drafts in the way that 
distributed mode works and your draft currently has no description of how 
centralized mode works.

Yours Irrespectively,

John

From: Huaimo Chen 
Sent: Tuesday, September 4, 2018 12:30 PM
To: John E Drake ; Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

Two drafts are presented in just two IETFs. For centralized mode and 
distributed one, one very important part is the their efficiency. It is better 
to give some time for others to propose some new or more efficient solutions. 
If one solution (say A) is much more efficient than another one (say B), which 
one (A or B) will you select?

Best Regards,
Huaimo
From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, September 4, 2018 12:02 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it.

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen 
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake ; Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it. We will add more in details.

Regarding to interactions with down-level nodes, can you give more details?

[JD]  Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=cQTQjUmBdJJJXLwNJuuICHOYwE09AmYdvM3tdz6JP5A=>,
 
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=7XTcJB8R7BWKwA6Gf9ZszZwlQUuVxDqnE-VkGBX2PPs=>
[HC] For this, our draft talks about it.
>Yours Irrespectively,
>
>John

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

Hi,

I have reviewed both of the flood reduction drafts and the draft referenced 
below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
document inferior in quality to the draft, draft-li-dynamic-flooding-05, from 
which it is derived.  For example, the referenced draft fails to include a 
description of the message used to deliver the flooding topology when using 
centralized mode, it neglects to include any analysis of error conditions, and 
it neglects to include any description of the interactions with down-level 
nodes.

Yours Irrespectively,

John

From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1) A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2) A procedure for establishing a new adjacency between a (new) node and  
an existing node supporting flooding reduction;

3) A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4) A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5) A TLV for distributing the priority of a node to become a leader;

6) Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li; lsr@ietf.org; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult