gmane.ietf.rtgwg

I-D Action: draft-ietf-rtgwg-ordered-fib-10.txt

2013-05-24T16:09:00

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

Title           : Framework for Loop-free convergence using oFIB
Author(s)       : Mike Shand
                          Stewart Bryant
                          Stefano Previdi
                          Clarence Filsfils
                          Pierre Francois
                          Olivier Bonaventure
Filename        : draft-ietf-rtgwg-ordered-fib-10.txt
Pages           : 26
Date            : 2013-05-24

Abstract:
   This document describes an illustrative framework of a mechanism for
   use in conjunction with link state routing protocols which prevents
   the transient loops which would otherwise occur during topology
   changes.  It does this by correctly sequencing the forwarding
   information base (FIB) updates on the routers.

   This mechanism can be used in the case of non-urgent (management
   action) link or node shutdo

I-D Action: draft-ietf-rtgwg-ipfrr-notvia-addresses-11.txt

2013-05-24T13:52:37

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

Title           : A Framework for IP and MPLS Fast Reroute Using Not-via Addresses
Author(s)       : Stewart Bryant
                          Stefano Previdi
                          Mike Shand
Filename        : draft-ietf-rtgwg-ipfrr-notvia-addresses-11.txt
Pages           : 32
Date            : 2013-05-24

Abstract:
   This document presents an illustrative framework for providing fast
   reroute in an IP or MPLS network through encapsulation and forwarding
   to "not-via" addresses.  The general approach described uses a single
   level of encapsulation and could be used to protect unicast,
   multicast, and LDP traffic against link, router, and shared risk
   group failure, regardless of network topology and metrics.

   The mechanisms presented in this document are purely illustrative of
   the general approach and do not constitu

Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ?

Alia Atlas — 2013-05-20T15:37:10

Pierre,

The end result should be an updated draft.  The list is good for discussing
what should go in and why :-)

Regards,
Alia


On Mon, May 20, 2013 at 11:27 AM, Pierre Francois <pierre.francois< at >imdea.org

_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ?

Pierre Francois — 2013-05-20T15:27:40

Alia, 

Thanks for your quick feedback. 

Let me check with my co-authors on whether we should change the doc to answer your comments and come back 
for a discussion based on ink-on-paper, or answer on the list. I am afraid of a never-ending thread for the later :)

Cheers,

Pierre.

On May 20, 2013, at 5:04 PM, Alia Atlas <akatlas< at >gmail.com> wrote:


_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ?

Alia Atlas — 2013-05-20T15:04:07

Hi Pierre,

Thank you for starting the conversation and a quick intro on the
differences.

When I look at this draft and PLSN, what I see is that the PLR is
definitionally either a type B router (since
it has an alternate that is safe for forwarding traffic or for link up it's
old primary) and that the PLR is then the
only router to apply the basic procedure.  However, the PLR may not have an
alternate available, unless MRT is used.

As draft-ietf-rtgwg-microloop-analysis-01 says in Sec 3.3:

" Another distinct situation is when the router does not support IPFRR or
could not repair the failure, the new primary next-hops do not satisfy the
safety condition, and there's no other neighbor that does, i.e. a type-C
situation. Unlike other routers in the network, the router directly
connected to the network does not have the old next-hop any more, and
cannot continue using it. Immediately switching to the new next-hops, on
the other hand, may result in a micro-loop. In this situation, the router
MUST discard traff

Progressing with draft-litkowski-rtgwg-uloop-delay-00 ?

Pierre Francois — 2013-05-20T11:57:39


Dear rtgwg list members, 

I would like to know your opinion about what we should do with http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that we presented in Orlando. 

The idea was to avoid microloops occurring in the direct neighbourhood of a node shutting down or bringing up a link in an IGP topology, by introducing some
fixed delay in the update of the FIB in the down case, and introducing a fixed delay in the propagation of the LSP describing the link as up in the up case. 

The solution is simple, will be released by some in the upcoming months, and the Orlando audience was seeming to find it interesting to work on.

Alia mentioned the interest of comparing this solution with the state of the art before going further with the doc, so here it comes. 

Generally, compared to other solutions, local-delay does not provide full coverage, as it only avoids all (but only)  microloops occurring locally to the affected node. However, 
in many networks, as shown by Stephane's analysis, it is

RE: any IPR on draft-ietf-rtgwg-cl-use-cases?

Lucy yong — 2013-05-14T20:22:05

I am not aware of  an IPR related to this draft.

Lucy

From: Alia Atlas [mailto:akatlas< at >gmail.com]
Sent: Tuesday, May 14, 2013 2:10 PM
To: rtgwg< at >ietf.org; draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org
Subject: any IPR on draft-ietf-rtgwg-cl-use-cases?

In preparation for a WG Last Call, could the authors please send to the mailing list whether they are aware of any IPR associated with draft-ietf-rtgwg-cl-use-cases?

Everyone else, if you know of any IPR, please send it to the list also.  If you're not sure - read the draft ;-)

thanks,
Alia
_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

RE: any IPR on draft-ietf-rtgwg-cl-use-cases?

Ning So — 2013-05-14T19:30:53

I am not aware of any IPR associated with the draft.

I am aware of a couple CL IPR.  They are related to specific CL solution/implementation, and have no claims impacting the stated draft here.

Best regards,

Ning So
Head of Network Architecture
Mobile Broadband Services
Tata Communications
(Cell) 972-955-0914

From: Alia Atlas [mailto:akatlas< at >gmail.com]
Sent: Tuesday, May 14, 2013 2:10 PM
To: rtgwg< at >ietf.org; draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org
Subject: any IPR on draft-ietf-rtgwg-cl-use-cases?

In preparation for a WG Last Call, could the authors please send to the mailing list whether they are aware of any IPR associated with draft-ietf-rtgwg-cl-use-cases?

Everyone else, if you know of any IPR, please send it to the list also.  If you're not sure - read the draft ;-)

thanks,
Alia
_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Re: any IPR on draft-ietf-rtgwg-cl-use-cases?

Malis, Andrew G (Andy — 2013-05-14T19:13:37

Alia,

I'm not aware of any IPR on this draft.

Cheers,
Andy

From: Alia Atlas <akatlas< at >gmail.com<mailto:akatlas< at >gmail.com>>
Date: Tuesday, May 14, 2013 15:10
To: "rtgwg< at >ietf.org<mailto:rtgwg< at >ietf.org>" <rtgwg< at >ietf.org<mailto:rtgwg< at >ietf.org>>, "draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org<mailto:draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org>" <draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org<mailto:draft-ietf-rtgwg-cl-use-cases< at >tools.ietf.org>>
Subject: any IPR on draft-ietf-rtgwg-cl-use-cases?
Resent-To: Andrew Malis <andrew.g.malis< at >verizon.com<mailto:andrew.g.malis< at >verizon.com>>, <curtis< at >occnc.com<mailto:curtis< at >occnc.com>>, <dave.mcdysan< at >verizon.com<mailto:dave.mcdysan< at >verizon.com>>, <lucy.yong< at >huawei.com<mailto:lucy.yong< at >huawei.com>>, <ning.so< at >tatacommunications.com<mailto:ning.so< at >tatacommunications.com>>

In preparation for a WG Last Call, could the authors please send to the mailing list whether they are aware of any IPR associated with draft-ietf-rtgwg-cl-use-cases?

Everyone else, if you know of any IPR, p

any IPR on draft-ietf-rtgwg-cl-use-cases?

Alia Atlas — 2013-05-14T19:10:21

In preparation for a WG Last Call, could the authors please send to the
mailing list whether they are aware of any IPR associated with
draft-ietf-rtgwg-cl-use-cases?

Everyone else, if you know of any IPR, please send it to the list also.  If
you're not sure - read the draft ;-)

thanks,
Alia
_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Biggest Fake Conference in Computer Science

2013-04-27T18:03:17

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit t

Re: WG Adoption Requested fordraft-litkowski-rtgwg-lfa-manageability-01

Alvaro Retana (aretana — 2013-04-22T22:48:36

Hi!

The period for comments has ended.

We received 11 comments supporting the adoption, which included 2 of the 3 contributors and 3 of the 4 authors.  Given that and the support at the last meeting, there is consensus to adopt the work.

Also, all the authors and contributors have confirmed that they are not aware of any IPR related to this draft.

Authors:  Please republish the draft with the updated name draft-rtgwg-lfa-manageability.

Thanks!

Alvaro.

On 4/2/13 1:17 PM, "Alvaro Retana (aretana)" <aretana< at >cisco.com<mailto:aretana< at >cisco.com>> wrote:

Hi!

The authors of 'Operational management of Loop Free Alternates' (http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-01) have requested that rtgwg adopt their draft as a WG document.

Authors and Contributors: Please respond indicating whether or not you are aware of any relevant IPR.  The draft will not progress until we have received a response from each author/contributor.

Please send any comments to the list by April 16, 2013.

Than

I-D Action: draft-ietf-rtgwg-mofrr-01.txt

2013-04-18T17:15:36

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

Title           : Multicast only Fast Re-Route
Author(s)       : Apoorva Karan
                          Clarence Filsfils
                          Dino Farinacci
                          IJsbrand Wijnands
                          Bruno Decraene
                          Uwe Joorde
                          Wim Henderickx
Filename        : draft-ietf-rtgwg-mofrr-01.txt
Pages           : 15
Date            : 2013-04-18

Abstract:
   As IPTV deployments grow in number and size, service providers are
   looking for solutions that minimize the service disruption due to
   faults in the IP network carrying the packets for these services.
   This draft describes a mechanism for minimizing packet loss in a
   network when node or link failures occur.  Multicast only Fast Re-
   Route (MoFRR) works by making simple enhancements to multicast

Re: Editors

Abdussalam Baryun — 2013-04-12T17:10:18

I appologies I made an error in sending to the destination address,

AB


On Fri, Apr 12, 2013 at 5:23 PM, Curtis Villamizar <curtis< at >occnc.com> wrote:

_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Re: WGLC on draft-ietf-rtgwg-cl-requirements-09

Curtis Villamizar — 2013-04-12T16:31:42

In message <CAG4d1rfBwqmyk2bdn-yKWgFcK_SWtSmM7TEQaZMwgCLP0hTO_Q< at >mail.gmail.com>
Alia Atlas writes:
 


Horray!  Been busy perhaps?




The CL Use Cases is a fairly quick read.  I would appreciate comments
on that document in particular.  It is purely informational, but as
long as the information is accurate (and useful) we could progress
this document.

CL Framework will be updated now that we have settled on a set of
documents for delay and jitter.  These are the soon to be updated
draft-atlas-mpls-te-express-path,
draft-ietf-ospf-te-metric-extensions, and
draft-previdi-isis-te-metric-extensions.  Other than that (and RFC6790
no longer being a draft), very little is expected to change for now.

CL Use Cases is farther along and it is easier to focus on one
document at a time.  Comments on either document would be greatly
appreciated, but if you have limited time, CL Use Cases first pleast.

Curtis

Re: Editors

Curtis Villamizar — 2013-04-12T16:23:18

In message <CADnDZ8-5ZPYKUU2hzXUnjX0WEEAVmofm_3ncLV-TNT7iY-dRuw< at >mail.gmail.com>
Abdussalam Baryun writes:
 


It is not clear from your email what draft you are talking about or
why this email is on the RTGWG mailing list.

I suggest that you try putting your comments in writing in an email
and send it to someone to review for clarity before sending to the
mailing list.  If you are talking about comments at the microphone at
a meeting, then perhaps written comments would clear things up.

In general written comments on the mailing list are supposed to count
for more than verbal comments at the mic at an IETF meeting, though
some would argue that is not the case.  Authors are obligated to
respond to comments about WG drafts, particularly in last call.  If
the comments were not clear, a response asking for clarification is
considered sufficient, awaiting the clarification.

Curtis

Re: WG Adoption Requested fordraft-litkowski-rtgwg-lfa-manageability-01

Martin Horneffer — 2013-04-12T11:13:46

 From the point of view of yet another operator:

I strongly support adopting this document.

Martin

Am 02.04.2013 19:17, schrieb Alvaro Retana (aretana):


##############################################
# Mail Account for technical purposes only
##############################################_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Re: WGLC on draft-ietf-rtgwg-cl-requirements-09

Alia Atlas — 2013-04-11T22:53:16

The WGLC on draft-ietf-rtgwg-cl-requirements-09 is long since done.  I
apologize for the delay.
We will work on progressing the updated draft-ietf-rtgwg-cl-requirements-10.

I'd encourage feedback on draft-ietf-rtgwg-cl-framework and
draft-ietf-rtgwg-cl-use-cases.  I expect that
we'll be doing a WG Last Call on at least one before Berlin.

Alia


On Thu, Feb 21, 2013 at 2:41 PM, Alia Atlas <akatlas< at >gmail.com> wrote:

_______________________________________________
rtgwg mailing list
rtgwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Editors

Abdussalam Baryun — 2013-04-10T00:53:40

Please note that I had difficulty in routing area or MANET WG explaing
my comments and discussing with editors just to understand my point of
views and edit few changes, but failed, it seems that they only follow
ADs, or I just don't know how they think.

Are editors taking any training?

AB

Re: IETF 86 Minutes Posted

Alvaro Retana (aretana — 2013-04-08T18:18:21

I updated the minutes with this correction.

Thanks!

Alvaro.

On 4/7/13 11:37 AM, "Curtis Villamizar" <curtis< at >occnc.com> wrote:

RE: IETF 86 Minutes Posted

Mingui Zhang — 2013-04-08T09:49:58

Clarification to the following comment.

[snip]
This is an area that telcos care about. The issue of unused links is that there is also capital investment into such unused links, not just power usage. ....  If I look at my networks, I will be reducing power by reducing parallel infrastructure. I think that if I was reducing power, I would do this first. If the re-engineering costs of the network are more than the power savings.
[snip]

The method is not to shut down links all the time. The power saving should be achieved in those off-peak hours. When the load increases, sleeping links should be waken up to carry traffic. Therefore sleeping links are not equal to unused links or down links. 

Thanks,
Mingui