Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Naiming Shen (naiming)]

I support.

- Naiming

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 20:26
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

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

[Naiming Shen (naiming)]

Support the adoption of the draft.

Regards,
- Naiming

> On Feb 11, 2019, at 2:44 AM, Christian Hopps  wrote:
> 
> 
> 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

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

Re: [Lsr] IPR Poll for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

[Naiming Shen (naiming)]

Sorry, someone reminded me that there is an IPR related to using the
draft-shen-isis-spine-leaf-ext scheme,

https://datatracker.ietf.org/ipr/2736/

thanks.
- Naiming

On Dec 17, 2018, at 3:22 PM, Naiming Shen (naiming) 
mailto:naim...@cisco.com>> wrote:


Hi,

I am not aware of any IPR applies to draft-shen-isis-spine-leaf-ext.

thanks.
- Naiming

On Dec 17, 2018, at 5:47 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Authors,

Are you aware of any IPR that applies to draft-shen-isis-spine-leaf-ext?

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

There are currently no 3 IPR disclosures so everyone should be aware of these - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-shen-isis-spine-leaf-ext

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] IPR Poll for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

[Naiming Shen (naiming)]

Hi,

I am not aware of any IPR applies to draft-shen-isis-spine-leaf-ext.

thanks.
- Naiming

On Dec 17, 2018, at 5:47 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Authors,

Are you aware of any IPR that applies to draft-shen-isis-spine-leaf-ext?

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

There are currently no 3 IPR disclosures so everyone should be aware of these - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-shen-isis-spine-leaf-ext

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] I-D Action: draft-ietf-isis-reverse-metric-17.txt

[Naiming Shen (naiming)]

Hi,

Thanks for Benjamin and Spencer’s good comments, we have update the
new version to reflect that. Please review.

Best Regards,
- Naiming

> On Dec 3, 2018, at 5:36 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : IS-IS Routing with Reverse Metric
>Authors : Naiming Shen
>  Shane Amante
>  Mikael Abrahamsson
>   Filename: draft-ietf-isis-reverse-metric-17.txt
>   Pages   : 15
>   Date: 2018-12-03
> 
> Abstract:
>   This document describes a mechanism to allow IS-IS routing to quickly
>   and accurately shift traffic away from either a point-to-point or
>   multi-access LAN interface during network maintenance or other
>   operational events.  This is accomplished by signaling adjacent IS-IS
>   neighbors with a higher reverse metric, i.e., the metric towards the
>   signaling IS-IS router.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-17
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-reverse-metric-17
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-reverse-metric-17
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Lsr] WG Adoption Call for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

[Naiming Shen (naiming)]

Support as a co-author.

thanks.
- Naiming

On Dec 1, 2018, at 4:54 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

This begins a two-week WG adoption call for the subject draft. As anyone who 
has been following the topic knows, there are a lot of proposal in this space. 
However, as WG co-chair, I believe this simple IS-IS extension doesn’t really 
conflict with any of the other more disruptive flooding proposals. Also, it is 
more mature and there is some implementation momentum. Note that I’m making 
every attempt to be transparent and it is perfectly ok to disagree with me. 
Please post your comments to this list before 12:00 AM, December 16th, 2018.

With respect to the more disruptive proposals, we are discussing our next steps.

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

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

Re: [Lsr] Genart last call review of draft-ietf-isis-reverse-metric-15

[Naiming Shen (naiming)]

Hi Stewart,

Thanks for detailed review and comments, please see some
replies inline. the modified version diff is attached, please reivew.

thanks.
- Naiming

Title: Diff: draft-ietf-isis-reverse-metric-15.txt - draft-ietf-isis-reverse-metric-15-rev.txt
 
 

 
 
 
 
 
 
 
   
   draft-ietf-isis-reverse-metric-15.txt   draft-ietf-isis-reverse-metric-15-rev.txt  
   
  Networking Working Group N. Shen Networking Working Group N. Shen
  Internet-Draft Cisco Systems Internet-Draft Cisco Systems
  Intended status: Standards Track   S. Amante Intended status: Standards Track   S. Amante
  
  Expires: April 19, 2019  Apple, Inc. Expires: April 24, 2019  Apple, Inc.
M. Abrahamsson   M. Abrahamsson
  T-Systems Nordic T-Systems Nordic
  
  October 16, 2018 October 21, 2018
   
 IS-IS Routing with Reverse MetricIS-IS Routing with Reverse Metric
  
 draft-ietf-isis-reverse-metric-15  draft-ietf-isis-reverse-metric-15-rev
   
  Abstract Abstract
   
 This document describes a mechanism to allow IS-IS routing to quicklyThis document describes a mechanism to allow IS-IS routing to quickly
 and accurately shift traffic away from either a point-to-point orand accurately shift traffic away from either a point-to-point or
 multi-access LAN interface during network maintenance or othermulti-access LAN interface during network maintenance or other
 operational events.  This is accomplished by signaling adjacent IS-ISoperational events.  This is accomplished by signaling adjacent IS-IS
 neighbors with a higher reverse metric, i.e., the metric towards theneighbors with a higher reverse metric, i.e., the metric towards the
 signaling IS-IS router.signaling IS-IS router.
   
   
  skipping to change at page 1, line 38 skipping to change at page 1, line 38
 Internet-Drafts are working documents of the Internet EngineeringInternet-Drafts are working documents of the Internet Engineering
 Task Force (IETF).  Note that other groups may also distributeTask Force (IETF).  Note that other groups may also distribute
 working documents as Internet-Drafts.  The list of current Internet-working documents as Internet-Drafts.  The list of current Internet-
 Drafts is at http://datatracker.ietf.org/drafts/current/.Drafts is at http://datatracker.ietf.org/drafts/current/.
   
 Internet-Drafts are draft documents valid for a maximum of six monthsInternet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at anyand may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate to use Internet-Drafts as referencetime.  It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."material or to cite them other than as "work in progress."
   
  
 This Internet-Draft will expire on April 19, 2019.This Internet-Draft will expire on April 24, 2019.
   
  Copyright Notice Copyright Notice
   
 Copyright (c) 2018 IETF Trust and the persons identified as theCopyright (c) 2018 IETF Trust and the persons identified as the
 document authors.  All rights reserved.document authors.  All rights reserved.
   
 This document is subject to BCP 78 and the IETF Trust's LegalThis document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF DocumentsProvisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of(http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documentspublication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respectcarefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document mustto this 

Re: [Lsr] I-D Action: draft-ietf-isis-reverse-metric-15.txt

[Naiming Shen (naiming)]

Corrected a misspelled name.

> On Oct 16, 2018, at 3:39 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : IS-IS Routing with Reverse Metric
>Authors : Naiming Shen
>  Shane Amante
>  Mikael Abrahamsson
>   Filename: draft-ietf-isis-reverse-metric-15.txt
>   Pages   : 14
>   Date: 2018-10-16
> 
> Abstract:
>   This document describes a mechanism to allow IS-IS routing to quickly
>   and accurately shift traffic away from either a point-to-point or
>   multi-access LAN interface during network maintenance or other
>   operational events.  This is accomplished by signaling adjacent IS-IS
>   neighbors with a higher reverse metric, i.e., the metric towards the
>   signaling IS-IS router.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-15
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-reverse-metric-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-reverse-metric-15
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Lsr] I-D Action: draft-ietf-isis-reverse-metric-14.txt

[Naiming Shen (naiming)]

Hi,

a new version of reverse-metric draft is updated for addressing the
comments from Barry and Eric.

Regards,
- Naiming

> On Oct 16, 2018, at 3:18 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : IS-IS Routing with Reverse Metric
>Authors : Naiming Shen
>  Shane Amante
>  Mikael Abrahamsson
>   Filename: draft-ietf-isis-reverse-metric-14.txt
>   Pages   : 14
>   Date: 2018-10-16
> 
> Abstract:
>   This document describes a mechanism to allow IS-IS routing to quickly
>   and accurately shift traffic away from either a point-to-point or
>   multi-access LAN interface during network maintenance or other
>   operational events.  This is accomplished by signaling adjacent IS-IS
>   neighbors with a higher reverse metric, i.e., the metric towards the
>   signaling IS-IS router.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-14
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-reverse-metric-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-reverse-metric-14
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13

[Naiming Shen (naiming)]

Hi Barry,

Thanks for the review and your suggestion makes sense. The original wording
is confusing. Also, as Tony has pointed out in the same thread, this sentence
was the original intention when start of the draft, but it has been extended for
other use cases described in section 1. How about this on top of your 
suggestions:

   For the use case in section 1.1, Node and Link Isolation, a router MUST limit
   the period during which it advertises a Reverse Metric TLV toward a neighbor
   only to the operational maintenance window period during which it wants that
   neighbor to temporarily update its IS-IS metric or Traffic Engineering 
parameters
   towards it.

Best Regards,
- Naiming

> On Oct 4, 2018, at 10:36 AM, Barry Leiba  wrote:
> 
> Reviewer: Barry Leiba
> Review result: Ready
> 
> This document is well written and seems ready to go.  The only security issue 
> I
> thought of as I read through it (attacking by spoofing a reverse metric) is
> covered in the Security Considerations section.
> 
> I found one sentence to be slightly ambiguous, but only very slightly.  In
> Section 3.5:
> 
>   A router MUST advertise a Reverse Metric TLV toward a neighbor only
>   for the operational maintenance window period during which it wants a
>   neighbor to temporarily update its IS-IS metric or Traffic
>   Engineering parameters towards it.
> 
> It begins to look like it's saying that a router MUST advertise this under
> certain conditions, and it took me a moment to get that it's actually
> *limiting* when it should be advertised (the "MUST" applies to the "only"
> clause).  If you think my suggested replacement reads well, you might use it;
> if not, no problem:
> 
>   A router MUST limit the period during which it advertises a Reverse Metric
>   TLV toward a neighbor only to the operational maintenance window period
>   during which it wants that neighbor to temporarily update its IS-IS metric
>   or Traffic Engineering parameters towards it.
> 

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

Re: [Lsr] I-D Action: draft-shen-isis-spine-leaf-ext-06.txt

[Naiming Shen (naiming)]

Hi Tony,

Thanks for the comments on the document. Lets see if we can work to resolve
some of the issues (i think mainly auto-tier’ing). Some replies inline.

On Oct 2, 2018, at 5:21 PM, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Gave it a read (markedly improved on -03 I think I read last), had chat with 
authors, rough summary for the list so we keep track:

a) As overall observation the disaggregation via leafs requesting from spines 
(more about that later ;-) is a very important rewrite in this version to 
ensure correctness in case of properly routing on fabrics that are missing 
links on bringup (the 
"you-cannot-know-that-you-don't-know-something-you-never-knew-before") ...

Sure.

b) 3.2 paragraph on extension working in multiple levels seems to imply that 
the spine level will not need disaggregation to next spine level up (if leaf 
extension is used spine to higher level spine). The solution is fully recursive 
and necessary so that may benefit from a paragraph or so. Additionally, two 
things need consideration
i) spines will need to know what up and what is down in such scenario. 
Possiblity is either configure levels on spines directly or per interface the 
L-capability
  ii) Flooding needs to be clarified that all the topology floods north but 
every level needs to generate a default route south
  iii) deployment like that allows for valley-free-routing and with that 
doesn't have to follow ECMP (more on that a bit down)

I think my original thinking was that, only real ‘bottom leaf’ nodes have true 
fixed connections to servers,
any other layer above that, probably can ‘re-route’ to the lower tier ‘spine 
nodes’ to reach the final leaf node.
But you are right, in multiple link down cases, if that needs to be handled, we 
should extend this in general.

c) 3.3: The flags are a pot-pourri of non-orthogonal stuff. T-bit seems to  
indicate Tier is valid but value 15 is invalid anyway, no explaination what R & 
L set @ same time mean, cat T be set with L? B IMO is dangerous and 
superfluous, it's used as "i'm a leaf, if you a leaf, route through me". leafs 
have basically no topology info @ can start happily loop the fabric pointing at 
each other or running triangles on the fabric ... I suggest removing the B-bit 
and go to the original "overload leafs"  (which RIFT happily adopted BTW ;-)

R normally is respond to the L from the neighbor, but can be set manually. Yes, 
lot people have concern about the
‘B’, we should take it out for now.

d) 3.3.2: CS-LSP without explanation is cryptic even for deep ISIS junkies, pls 
refer to 7356?  My opinion didn't change, craming the stuff into hellos is a 
fragile design

Sure.

e) 3.4:
  i) computing "distance from the top" is a first, optimistic approach and 
viable only if one is willing to assume miscabling never happens (what if 
couple leafs are @ different distances) and worse, does not consider fabrics 
with PoDs of differnt heights (a reality for some people)
ii) unequal cost sharing works if all levels repeat the leaf-spine pattern 
since we have valley-free-routing. If the spine levels are running flat-ISIS 
the traffic may show up in a point where it will bow-tie the fabric to get to 
destination (I think it can loop as well but need to think more and possibly 
I'm wrong since leafs should never be transits)

Lets talk more on a proper scheme.

f) 3.4.1: The section is incomplete, following example needs consideration for 
it to work correctly (unless disregarded) . sorry for crappy drawing. if A 
wants to properly disaggregate it needs to request A, B and either C or D

   +-+   +-+  +-+  +-+
+--+A|   |B+-+ ++-+C+--+   |D+-+
|  +++   +++ |  | +++  |   +++ |
|   | |  |  |  |   ||  |
|   |  +--+  |  |  |   ||  |
|   |  | |  |  |   ||  |
|   |  | +-+   ||  |
|   |  | |   |  |  ||  |
|   |  | | ++  |
|   |  | | | |  |  |   |
+-+  +-+  +++  |
|  | | |  | |  ||  |
   +++ | | | +++| +++  +++ |
   |1+-+-+-++|2|+-+3|  |4+-+
   +-+   +-+  +-+  +-+


Right. this portion needs to be beefed up, to specify the multiple link down 
behavior in general.

Best Regards,
- Naiming

--- tony

On Mon, Jun 18, 2018 at 1:30 PM Naiming Shen (naiming) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Hi LSR’er,

A new version of spine-leaf is-is draft is posted. The main change
is adding a new bit from ‘link-attribute’ sub-tlv to indicate there is
no need to flood out on this interface, used by the spine nodes
and for the case where the spine nodes are part of the dynamic
flooding domain.

Please review and comment.

Regards,
- Naiming

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

[Naiming Shen (naiming)]

Agreed. Also for the relatively-long term solution, I doubt there is
an one-size-fits-all solution. We need to have enough building blocks
in protocols and any data center design/operation can utilize with
to achieve their operational goal.

Regards,
- Naiming

On Aug 22, 2018, at 5:22 PM, Dean cheng 
mailto:dean.ch...@huawei.com>> wrote:

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Li 
mailto:tony1ath...@gmail.com>>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


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

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

Re: [Lsr] I-D Action: draft-ietf-isis-reverse-metric-12.txt

[Naiming Shen (naiming)]

Hi LSRers,

A new version of reverse metric draft is posted, to add the text for
new registry for sub-TLV in this document. Please review.

thanks.
- Naiming


> On Aug 21, 2018, at 10:05 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : IS-IS Routing with Reverse Metric
>Authors : Naiming Shen
>  Shane Amante
>  Mikael Abrahamsson
>   Filename: draft-ietf-isis-reverse-metric-12.txt
>   Pages   : 14
>   Date: 2018-08-21
> 
> Abstract:
>   This document describes a mechanism to allow IS-IS routing to quickly
>   and accurately shift traffic away from either a point-to-point or
>   multi-access LAN interface during network maintenance or other
>   operational events.  This is accomplished by signaling adjacent IS-IS
>   neighbors with a higher reverse metric, i.e., the metric towards the
>   signaling IS-IS router.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-12
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-reverse-metric-12
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-reverse-metric-12
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] IPR poll for draft-ietf-isis-reverse-metric-10

[Naiming Shen (naiming)]

I’m not aware of any IPR related to this draft.

Regards,
- Naiming

> On Jun 18, 2018, at 3:31 PM, Christian Hopps  wrote:
> 
> Hi Authors,
> 
> Can you please respond (including the mailing list) indicating if you are 
> aware of any IPR relating to draft-ietf-isis-reverse-metric?
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

[Lsr] Fwd: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt

[Naiming Shen (naiming)]

Hi LSR’er,

A new version of spine-leaf is-is draft is posted. The main change
is adding a new bit from ‘link-attribute’ sub-tlv to indicate there is
no need to flood out on this interface, used by the spine nodes
and for the case where the spine nodes are part of the dynamic
flooding domain.

Please review and comment.

Regards,
- Naiming

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
Date: June 18, 2018 at 1:21:31 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Reply-To: internet-dra...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


   Title   : IS-IS Routing for Spine-Leaf Topology
   Authors : Naiming Shen
 Les Ginsberg
 Sanjay Thyamagundalu
Filename: draft-shen-isis-spine-leaf-ext-06.txt
Pages   : 18
Date: 2018-06-18

Abstract:
  This document describes a mechanism for routers and switches in a
  Spine-Leaf type topology to have non-reciprocal Intermediate System
  to Intermediate System (IS-IS) routing relationships between the
  leafs and spines.  The leaf nodes do not need to have the topology
  information of other nodes and exact prefixes in the network.  This
  extension also has application in the Internet of Things (IoT).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-shen-isis-spine-leaf-ext-06
https://datatracker.ietf.org/doc/html/draft-shen-isis-spine-leaf-ext-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-shen-isis-spine-leaf-ext-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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