Re: Charter Update (Discussion)

On 08/11/2011 17:20, András Császár wrote: I think we should first see if there is a solution which provides full coverage and practical (=reasonable complexity). One problem with non-full-coverage solutions is bidirectional coverage. I.e. even if a flow is covered for a failure in one directi

Re: Charter Update (Discussion)

failure cannot be solved by C with LFA, so ultimately the Src-Dest traffic is screwed. András -Original Message- From: rtgwg-boun...@ietf.org [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: 2011. november 8. 18:54 To: rtgwg@ietf.org Subject: Re: Charter Update (Di

Re: Charter Update (Discussion)

gwg-boun...@ietf.org [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, November 09, 2011 6:56 PM To: András Császár Cc: rtgwg@ietf.org Subject: Re: Charter Update (Discussion) Hi András Yes, it is true that for that topology fragment there is no bidirectional LFA solutio

Re: Charter Update (Discussion)

On 15/11/2011 21:36, Sriganesh Kini wrote: Hi, I agree that having a solution with full coverage is very useful because it removes the need for complicated analysis to determine what is protected versus what is not (and worse, how that changes as the topology change). But the solution has to be

Re: Charter Update (Discussion)

is not as much of a concern. On Tue, Nov 15, 2011 at 2:14 PM, Stewart Bryant wrote: On 15/11/2011 21:36, Sriganesh Kini wrote: Hi, I agree that having a solution with full coverage is very useful because it removes the need for complicated analysis to determine what is protected versus what is

Re: Charter Update (Discussion)

;Eric Osborne (eosborne)" wrote: -Original Message- From: rtgwg-boun...@ietf.org [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant (stbryant) Sent: Wednesday, November 16, 2011 7:09 AM To: Sriganesh Kini Cc: rtgwg@ietf.org Subject: Re: Charter Update (Discussion) Unf

Fwd: Re: Review of draft-ietf-rtgwg-lfa-applicability-04

FYI Original Message Subject:Re: Review of draft-ietf-rtgwg-lfa-applicability-04 Date: Wed, 04 Jan 2012 11:10:15 + From: Stewart Bryant Reply-To: stbry...@cisco.com To: Shawn Emery , draft-ietf-rtgwg-lfa-applicability@tools.ietf.org, rtgwg-cha

Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

Andras I think that you omitted to note that RLFA supports incremental deployment well, and in particular needs no new protocols. This is in contrast to all of the alternatives that have been put on the table, which require the on-repair-path nodes to change. The approach proposed here is to pub

Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

On 01/06/2012 08:33, András Császár wrote: Hi Stewart, I think that you omitted to note that RLFA supports incremental deployment well, and in particular needs no new protocols. This is in contrast to all of the alternatives that have been put on the table, which require the on-repair-path nodes

Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

Gabor Those are very reasonable questions, however it is quite a difficult problem to address since we need real topologies and these are only available under non-disclosure from network operators. This has historically been a particular problem for the academic IPFRR researchers. Section 7.3 of

Re: opinions on adoption of draft-shand-remote-lfa as a WG draft

I have refreshed the draft. A couple of minor changes, that will not impact the review: 1) Fixed Mike's affiliation and email address 2) Fixed Ning's email address (need to fix his affiliation when I know what to put in) 3) Fixed a formatting error (section 8 was not shown as a proper section)

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

This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi

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

On 10/09/2012 13:58, Saku Ytti wrote: On 9 September 2012 22:45, Stewart Bryant wrote: The expected use of this technology in the failure case is in conjunction with IPFRR where following a protected failure, and in the absence of a convergence control technology, microloops may form and/or

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

riginate at R, or arrive at R via some un-shown network fragment. - Stewart Allwyn. Stewart Bryant wrote: Saku The expected use of this technology in the failure case is in conjunction with IPFRR where following a protected failure, and in the absence of a convergence control technology, microl

Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ???

On 11/12/2012 10:25, Hannes Gredler wrote: fellow authors of the remote-LFA draft, To date no IPR declaration has been filed for this draft. Can you please declare any IPR you may have (if any) and publish the licensing terms, please. tx, /hannes Hannes Thank you for bringing this to our a

Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

Hannes The draft as it stands is not MPLS specific and thus I am not convinced we should add the information you propose to this draft, although perhaps some text could go in a new section. However if we include this text, we need to consider what we should say about IP tunnels. However it might

Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

On 12/12/2012 15:27, Peter Psenak wrote: Hi Hannes, please see inline: On 12.12.2012 15:49, Hannes Gredler wrote: for the OSPF routing protocol: A PLR router should connect to the address traffic-engineering deployments: why do we need to distinguish between TE and non-TE deployments?

Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

On 12/12/2012 16:34, Peter Psenak wrote: Hannes, On 12.12.2012 17:05, Hannes Gredler wrote: in favor of explicit advertisement, i'd rather do 3 rules here : 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself 2. PQ node TE adress, if it is advertised as /32 pre

Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

On 13/12/2012 20:35, Les Ginsberg (ginsberg) wrote: Hannes - should be go down and spin off dedicated drafts for OSPF and IS-IS to explicitly advertise the transport IP address ? Speaking specifically about IS-IS, why would we need to invent yet another type of advertisement specifically for

Re: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses

Adrian How about if we add a new first section that says: "This document describes a method of providing fast re-route in an IP or MPLS network based on the use of an IP address known to avoid the failure. At the time of publication there is no immediate demand to deploy this technology, however

Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ???

lose the loop.. This issue has been fixed and the IPR now shows up. Alvaro. On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" wrote: There was a declaration against draft-shand-remote-lfa-0, but the chairs did not set the replacement status correctly when draft-ietf-rtgwg-remote-lfa-00

Re: Routing Directorate Review of "Framework for Loop-free convergence using oFIB"

On 30/01/2013 18:33, Acee Lindem wrote: Authors, et al, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request.

Re: A query on RIPv2

The confusion seems to be whether the AH, which gets carried as a special type of RIP entry, is an RTE or not. I can see arguments both ways, although the fact that this has taken 25 years to surface suggests that most implementers have subscribed to a common view that the an AH is not an RTE, an

Re: A query on RIPv2

8, 2013, at 10:03 AM, Stewart Bryant wrote: The confusion seems to be whether the AH, which gets carried as a special type of RIP entry, is an RTE or not. I can see arguments both ways, although the fact that this has taken 25 years to surface suggests that most implementers have subscribed to a com

Fwd: Status BOF in Berlin

.@ietf.org - Stewart Original Message Subject:Status BOF in Berlin Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant Reply-To: stbry...@cisco.com To: routing-discuss...@ietf.org CC: sta...@ietf.org STATUS * Name: Stacked Tunnels for Sour

Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

one of the authors directly (by email), but no answers were received. That's why I send this message to the list. I have never post any message to these mailing lists and I hope I did not spamming it. On 06/25/2013 06:53 PM, Acee Lindem wrote: Hi Stewart, See inline. On 6/20/13 6:59 AM,

Re: draft-ietf-rtgwg-remote-lfa - ready for WGLC? - some comments and questions

On 26/06/2013 14:13, Levente Csikor wrote: Levente In each case below the conditions are surely fulfilled if n=e thus I think that in each case the condition needs to be changed to : some node n!={s or e} In order to not to read our full papers and searching the answers, I copied here the rele

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues le

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

..@orange.com> *De :*rtgwg-boun...@ietf.org [mailto:rtgwg-boun...@ietf.org] *De la part de* Stewart Bryant *Envoyé :* mercredi 2 octobre 2013 13:26 *À :* Alvaro Retana (aretana) *Cc :* draft-ietf-rtgwg-remote-...@tools.ietf.org; rogeriomariano; rtgwg@ietf.org *Objet :* Re: I-D Action: draft-ietf-rtg

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

3 6 37 86 97 52 stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com> *De :*Stewart Bryant [mailto:stbry...@cisco.com] *Envoyé :* lundi 7 octobre 2013 17:56 *À :* LITKOWSKI Stephane DTF/DERX *Cc :* Alvaro Retana (aretana); draft-ietf-rtgwg-remote-...@tools.ietf.org; rogeriomariano; rtgwg@i

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

f Future tél. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com> *De :*Stewart Bryant [mailto:stbry...@cisco.com] *Envoyé :* mardi 8 octobre 2013 11:38 *À :* LITKOWSKI Stephane DTF/DERX *Cc :* Alvaro Retana (aretana);

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

is my preferred approach because it is certain to work. Let me see if I can craft some text. Stewart /hannes On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote: [ … ] On 08/10/2013 08:06, stephane.litkow...@orange.com wrote: [ .. ] [SLI] Some nodes are not accepting any TLDP session at all

Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

Without doing a whole load of investigation, we should assume that the IPR disclosures that apply to rlfa apply to this draft. I will therefore set in place the process to extend the disclosure. Stewart On 01/10/2013 19:07, Jeff Tantsura wrote: Hi, Question to the authors of the draft about th

Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

I really would like to get the base done - it's been a long time. Stewart On 10/10/2013 16:23, Hannes Gredler wrote: one more reason for making it part of the base spec ;-) - /hannes On Oct 10, 2013, at 5:14 PM, Stewart Bryant wrote: Without doing a whole load of investigation, we s

Re: algorithm description for draft-ietf-rtgwg-remote-lfa

Please see notes inline. Here is the current candidate algorithm text. I added lots of comments for my personal checking of the algorithm and my guess is that they will be of use to reader and reviewers further down the line. Once this is correct we will need to add a glossary of terms. 4.3.

Re: issue with cost-based formulation of extended P-space in draft-ietf-rtgwg-remote-lfa-02

I think that the new text is correct: In cost terms a router (P) is in extended P-space if the shortest path cost N->P is strictly less than the shortest path cost N->S->E->P. In other words, once the packet it forced to N by S, it is lower cost for it to continue on to P by any path except on

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com> *De :*rtgwg-boun...@ietf.org [mailto:rtgwg-boun...@ietf.org] *De la part de* Stewart Bryant *Envoyé :* mercredi 2 octobre 2013 13:26 *À :* Alvaro Retana (aretana) *Cc :* draft-ietf-rtgwg-remote-...@tools.ietf.org; rogeriomariano;

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

How about the following text: To establish an targeted LDP session with a candidate PQ node the repairing node (S) needs to know what IP address PQ is willing to use for targeted LDP sessions. Ideally this is provided by PQ advertising this address in the IGP in use. Which address is used, how

Re: algorithm description for draft-ietf-rtgwg-remote-lfa

On 11/10/2013 14:29, stephane.litkow...@orange.com wrote: Completely agree with Chris. Moreover having the algorithm part described clearly inside the main paragraphs of the document rather than the appendix is completely inline with what has been done for basic LFA specification (RFC 5286 P

candidate-draft-ietf-rtgwg-remote-lfa-03.txt

I have edited draft-ietf-rtgwg-remote-lfa-03.txt, and in view of the cut-off have put a copy here: https://www.dropbox.com/s/kahbqvrsww40qua/candidate-draft-ietf-rtgwg-remote-lfa-03.txt Stewart ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

I propose a slight change to the text: In the absence of a protocol to learn the prefered IP address for targetted LDP, a tie-breaking mechanism is required. Unless otherwise configured, an LSR should attempt a targeted LDP session with the *local* IP address with the lowest numerical value a

Re: 答复: 答复: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Please note Cisco declared IPR on RFC 5715 section 6.1 - Stewart On 22/10/2013 10:20, Mike Shand wrote: So you have described the difference with OFIB (RFC 6976), but how does your proposal differ from "incremental cost advertisement" as described in RFC 5715 section 6.1? Mike On 22/10/20

Re: issue #1 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt

le section 3.1" is not clear. SB> I have inspected all instances of PQ and used some combination of SB> remote LFA repair target, PQ and remote LFA repair target (PQ) as SB> seemed appropriate - Stewart -Original Message- From: rtgwg-boun...@ietf.org [mailto:rtgwg-boun..

Re: issue#2 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt

On 29/10/2013 16:36, Chris Bowers wrote: The text in section 4.2.1 and 4.2.2 describing the (unextended) P-space calculation should be removed. I agree with the Editor's note below in the comments for the Compute_Extended_P_Space() function in the algorithm pseudocode that the "if statement m

candidate2-draft-ietf-rtgwg-remote-lfa-03.txt

Candidate 2 now in dropbox https://www.dropbox.com/s/yvzvvra3ie8ojv0/candidate2%20-draft-ietf-rtgwg-remote-lfa-03.txt Will upload to IETF site as soon as am able Stewart ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg

candidate2-draft-ietf-rtgwg-remote-lfa-03

I don't think this got posted as aparently too long so sending it as simple ascii Candidate 2 now in dropbox https://www.dropbox.com/s/yvzvvra3ie8ojv0/candidate2%20-draft ietf-rtgwg-remote-lfa-03.txt Will upload to IETF site as soon as am able Stewart ___

Re: candidate2-draft-ietf-rtgwg-remote-lfa-03

Sorry for the typo. The link is https://www.dropbox.com/s/yvzvvra3ie8ojv0/candidate2%20-draft-ietf-rtgwg-remote-lfa-03.txt or *http://tinyurl.com/kwr5ytz Stewart * On 01/11/2013 18:31, Alia Atlas wrote: https://www.dropbox.com/s/yvzvvra3ie8ojv0/candidate2%20-draft ietf-rtgwg-remote-lfa-03.t

relmote lfa draft edits

Here you go... On 11/5/13 9:38 AM, "Stewart Bryant" wrote: Hi Acee Any chance of a copy of your mins - no matter how rough - so I can start on my doc actions. Stewart Remote LFA - Stewart Bryant (See slides) - See changes to current version in slides. - Steward doe

Fwd: New Version Notification for draft-ietf-rtgwg-remote-lfa-04.txt

:New Version Notification for draft-ietf-rtgwg-remote-lfa-04.txt Date: Fri, 22 Nov 2013 13:13:34 -0800 From: To: Mike Shand , Stefano Previdi , "So Ning" , Ning So , Clarence Filsfils , Stewart Bryant A new version of I-D, draft-ietf-rtgwg-remote-lfa-04.txt has been su

Re: IPR Claims related to draft-ietf-rtgwg-remote-lfa

I have declared everything that I can think of that applies to this draft. Stewart On 04/12/2013 13:37, Alvaro Retana (aretana) wrote: Hi! In parallel to the WGLC for this draft, I want to formally ask the authors (no additional contributors are listed in the latest version of the draft) to

Re: Regarding cost based algorithm for finding Extended P-Space.

On 03/01/2014 11:35, Bharath R wrote: Hi, I have a query on cost based formula for finding Extended P-space. The current formula applies to Node y that is 1). D_opt(Ni, Y) < (D_opt(Ni, S) + D_opt(S, Protected_link.RemoteNode) + D_opt(Protected_link.RemoteNode, Y)) Bharath I cannot see this te

Re: FW: Regarding cost based algorithm for finding Extended P-Space.

Mike and I did some work on this this afternoon We propose the following algorithm for calculating extend P space with avoids stub node problem and also addresses a problem in the pseudocode that excluded the use of a parallel link. ///

Re: WGLC for draft-ietf-rtgwg-remote-lfa

I am in the process of working through the comments received. I have started with Alia's comments, which I have addressed as indicated below. I will post this as version -05. I will incorporate the other comments and comments on the changes made in -05 in -06. On 06/12/2013 23:03, Alia Atlas w

Re: WGLC for draft-ietf-rtgwg-remote-lfa

On 04/12/2013 20:26, Pushpasis Sarkar wrote: Hi Stewart/Alvaro, It maybe a very late, but I wanted to point the following issue with the algorithm/psuedocode text provided in section 4.3. / // // Calculate extended P-space //

Re: comments on draft-ietf-rtgwg-remote-lfa-05

On 23/05/2014 13:43, Chris Bowers wrote: Authors, Below are two comments on draft-ietf-rtgwg-remote-lfa-05. 1) A section should be added to the document clarifying what the expected behavior is for RLFA when routers advertise themselves as not desiring to carry transit traffic or links have bee

Re: I-D Action: draft-ietf-rtgwg-remote-lfa-06.txt

Working Group Working Group of the IETF. Title : Remote LFA FRR Authors : Stewart Bryant Clarence Filsfils Stefano Previdi Mike Shand Ning So Filename

Re: comments on draft-ietf-rtgwg-remote-lfa-05

Chris I would like to take this together with final review coments from the WGCs Stewart On 28/05/2014 19:54, Chris Bowers wrote: See inline [CB] for comment on the new section 4.4. Chris *From:*Stewart Bryant [mailto:stbry...@cisco.com] *Sent:* Friday, May 23, 2014 10:11 AM *To:* Chris

Re: IETF 90 RTGWG Agenda

On 09/07/2014 18:11, Jeff Tantsura wrote: Hi RTGWG: The agenda for IETF 90 RTGWG has been posted: https://datatracker.ietf.org/meeting/90/agenda/rtgwg Looking forward to seeing you in Toronto! Cheers, Jeff ___ rtgwg mailing list rtgwg@ietf.org https

Re: IETF 90 RTGWG Agenda

chive/web/time/current/maillist.html > > Regards! > > -Qin > > *发 件人:*rtgwg [mailto:rtgwg-boun...@ietf.org] *代 表 *Stewart Bryant > *发 送时间:*2014年7月14日17:56 > *收件人:*Jeff Tantsura; rtgwg@ietf.org > *主题:*Re: IETF 90 RTGWG Agenda > > On 09/07/2014 18:11, Jeff Tantsura wr

Re: rtgwg Rechartering

On 23/09/2014 09:27, bruno.decra...@orange.com wrote: Hi, Please find below 2 feedbacks: 1)Small topics "and may work on specific small topics that do not fit with an existing working group." "RTGWG may also work on specific small topics that do not fit with an existing working group."

Re: rtgwg Rechartering

It's a can't have linked I-Ds (like linked files) so that they show up in the document trail in other relevant WGs. - Stewart On 23/09/2014 14:25, Acee Lindem (acee) wrote: Hi Bruno, On Sep 23, 2014, at 4:27 AM, > > wrote:

Re: rtgwg Rechartering

(two missing words!) On 23/09/2014 15:49, Stewart Bryant wrote: It's a pity we can't have linked I-Ds (like linked files) so that they show up in the document trail in other relevant WGs. - Stewart On 23/09/2014 14:25, Acee Lindem (acee) wrote: Hi Bruno, On Sep 23, 2014,

Re: Comments on draft-ietf-rtgwg-remote-lfa

Alvaro Thanks. Please see inline. On 22/09/2014 23:55, Alvaro Retana (aretana) wrote: > Hi! > > After a long wait, I finally got to this.. > > I do have some comments (minor and nits) that I would like addressed. > As you look at these I will get the write up ready to send to the IESG > --- you c

Re: Comments on draft-ietf-rtgwg-remote-lfa

On 23/09/2014 15:30, Alvaro Retana (aretana) wrote: A couple more comments as I'm writing the shepherd's doc: 1. Please don't forget to look at the idnits: https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-remote-lfa-06.txt I think it's all historic stuff but I

Re: comments on draft-ietf-rtgwg-remote-lfa-05

. I am trying to figure out if I need more OSPF and ISIS refs. I could argue that anyone that needs to implement this will know them and anyone that needs the ref should not be implementing it :) However I am not sure the IESG will agree :) Stewart On 30/05/2014 13:28, Stewart Bryant wrote

Re: comments on draft-ietf-rtgwg-remote-lfa-05

forwards SPFs” should be “per-neighbor forward SPFs” (an error in my original text). Done Thanks Stewart Chris *From:*Stewart Bryant [mailto:stbry...@cisco.com] *Sent:* Wednesday, September 24, 2014 12:53 PM *To:* Chris Bowers; rtgwg@ietf.org *Subject:* Re: comments on draft-ietf-rtgwg-remote

Re: comments on draft-ietf-rtgwg-remote-lfa-05

Done. Stewart On 25/09/2014 20:35, Alvaro Retana (aretana) wrote: [WG Chair hat off.] Stewart: Hi! One of the things that we changed in rfc6987 wrt rfc3137 is a definition of a new architectural constant to avoid confusion on the interpretation of LSInfinity. The new name is 'MaxLinkMetri

Re: Router backdoor threat model

For much of this you could cross out router and write in host. It all applies to many networking functions other that routers such as switches, firewalls, NFV functions etc. I am not convinced that RTGWG is the right place for this, a good case could be made for OPSWG or somewhere in SEC. S

Re: maturity of the MRT technology

re drafts :-) Regards, Alia On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <mailto:l...@pi.nu>> wrote: Working Groups, We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been posted to the mpls wg mailing list. In his MPLS-RT review Stewart Bryan

Re: maturity of the MRT technology

roups, We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been posted to the mpls wg mailing list. In his MPLS-RT review Stewart Bryant says: "I have concerns about whether or not MRT technology has the maturity expected in the standards track. However that decision needs to

Re: maturity of the MRT technology

ds. We have an existence proof for some of the above in transport networks which can't react in that sort of time and rely use an SDN approach. - Stewart Regards, Alia On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant <mailto:stbry...@cisco.com>> wrote: I have been mulling t

Re: maturity of the MRT technology

On 03/12/2014 19:59, Uma Chunduri wrote: >the method of calculating the >repair topology itself ought to be private to the orchestrator. When we agree to standardize the IPFRR related parameters, IMO it’s important to standardize the relevant algorithm too regardless of where it’s used. If

Re: AD review comments on draft-ietf-rtgwg-remote-lfa-08

On 12/12/2014 00:00, Alia Atlas wrote: Alia thank you for your review. Here are my responses and the changes make to -09 Minor Comments: 1) In Sec 2, 3rd paragraph, in the sentence: "The single node in both S's P-space and E's Q-space is C; thus node C is selected as the repair tunnel's end-p

Re: Adrian Farrel's Discuss on draft-ietf-rtgwg-remote-lfa-09: (with DISCUSS and COMMENT)

Mike and I have a session with Adrian tomorrow to work through his discuss points it is 2pm UK. You are welcome. I expect that it will mostly address definitions. Just to pick on one point: Why is the discussion of microloops on network re-converges considered to be a management cons

Re: Adrian Farrel's Discuss on draft-ietf-rtgwg-remote-lfa-09: (with DISCUSS and COMMENT)

Adrian, Mike and I just worked through the definitions and tightened them up. We then looked at some of the usage in section 2 and made that more precise. I fixed the use of the term draft and adopted Barry's title, but without including the abbreviations (I can put them in if people want). H

Adrian Farrel's Comments on draft-ietf-rtgwg-remote-lfa

Comment (2015-01-06 for -10) SB> Adrian here is the commentary on the resolution of your comments: Although it causes some pain with abbreviations and a little more care in explanation, you need to put the Introduction as the first section in the document. The RFC editor will insist on this, so

Re: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Actually I was going to propose this myself. ARC is a very interesting approach in that it deals quite well with multiple failures since the repair is localized to the repair arc making it possible to do multiple repairs. I still wonder whether we know enough about the relative merits of the va

Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

+1 Stewart On 28/10/2015 13:23, Mike Shand wrote: I think this just goes to show how confusing the distance based definitions of this stuff can be! While I agree that an implementation may use those techniques, I find it MUCH simpler to understand using the traditional definitions. Mike

WGLC for draft-rtgwg-mrt-frr-architecture

Hi, I am sorry that this review is late, but a number of personal matters needed priority. Hopefully you can accept it still. Firstly my high order bit, and I suspect I will be in the rough on this. I am not convinced that this is the best solution that we can produce to this problem, and I am c

WGLC for draft-rtgwg-mrt-frr-architecture

Resend due to problem sending to the document alias Hi, I am sorry that this review is late, but a number of personal matters needed priority. Hopefully you can accept it still. Firstly my high order bit, and I suspect I will be in the rough on this. I am not convinced that this is the best sol

Re: WGLC for draft-rtgwg-mrt-frr-architecture

Another couple of comments on this draft. The technique you use of selecting a single node and forming two trees rooted at that node should really be noted up front in the summary. A consequence of this is that when you add a node or when the root node fails the trees and hence the FRR paths may

Re: WGLC for draft-rtgwg-mrt-frr-architecture

cept, and conservative in what you send” - Jon Postel *From:*rtgwg [mailto:rtgwg-boun...@ietf.org] *On Behalf Of *Stewart Bryant *Sent:* 04 December 2015 02:22 *To:* draft-rtgwg-mrt-frr-architect...@ietf.org <mailto:draft-rtgwg-mrt-frr-architect...@ietf.org>; rtgwg@ietf.org <mailto:r

Re: WGLC for draft-rtgwg-mrt-frr-architecture

Resending with the correct draft alias On 07/12/2015 11:07, Stewart Bryant wrote: Hi Anil Please see inline. Note that here we are just discussion some of the points raised. - Stewart On 06/12/2015 04:38, Anil Kumar S N (VRP Network BL) wrote: Hi Bryant, Please find my observation on

Re: WGLC for draft-rtgwg-mrt-frr-architecture

On 07/12/2015 11:11, Stewart Bryant wrote: Resending with the correct draft alias On 07/12/2015 11:07, Stewart Bryant wrote: Hi Anil Please see inline. Note that here we are just discussion some of the points raised. - Stewart On 06/12/2015 04:38, Anil Kumar S N (VRP Network BL) wrote

Re: WGLC for draft-rtgwg-mrt-frr-architecture

Please see more comments inline - Stewart On 08/12/2015 12:07, Anil Kumar S N (VRP Network BL) wrote: Hi Stewart, Request you to see inline for reply. Thanks & Regards Anil S N “Be liberal in what you accept, and conservative in what you send” - Jon Postel *From:*Stewart Br

draft-ietf-rtgwg-mrt-frr-algorithm - some comments

Hi, I am sorry for the late comments I have looked at the algorithm draft and have a some top level concerns. Firstly you have the sections that describe the operation in detail and the python code both as normative. That is always a dangerous thing to do since it is not clear which has priorit

Re: WGLC for draft-rtgwg-mrt-frr-architecture

Alvaro My experience of the IETF is that it tries quite hard to get to a single solution per problem domain on the standards track. Now maybe the IESG position on this has changed but the expectation is that normally there would only be a single ST RFC. Also ST normally expresses a view that the

Re: WGLC for draft-rtgwg-mrt-frr-architecture *and* draft-ietf-rtgwg-mrt-frr-algorithm

Hopefully the authors will respond to my last call comments. Also I think that Rob's characterization of the operational issues need a response. - Stewart On 15/12/2015 16:07, Alvaro Retana (aretana) wrote: Hi! We have concluded the WGLC. There are some clarifying comments and nits that wer

Re: draft-ietf-rtgwg-mrt-frr-algorithm - some comments

[mailto:rtgwg-boun...@ietf.org] *On Behalf Of *Stewart Bryant *Sent:* Wednesday, December 09, 2015 5:34 AM *To:* draft-ietf-rtgwg-mrt-frr-algori...@tools.ietf.org; rtgwg@ietf.org; rtgwg-cha...@tools.ietf.org *Subject:* draft-ietf-rtgwg-mrt-frr-algorithm - some comments Hi, I am sorry for the late

Re: WGLC for draft-rtgwg-mrt-frr-architecture

Hi Chris Thanks for addressing my comments. I will trim the email to just the areas that need fur On 21/12/2015 14:47, Chris Bowers wrote: === 1. Introduction SB> The text should start with the invariants and assumptions to SB> correctly scope the claims in the introduction.

Re: WGLC for draft-rtgwg-mrt-frr-architecture

places in the architecture document where similar clarifications should be made? Chris -Original Message- From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, December 04, 2015 9:55 AM To: draft-rtgwg-mrt-frr-architect...@ietf.org; rtgwg@ietf.org; Alv

Re: WGLC for draft-rtgwg-mrt-frr-architecture

On 21/12/2015 15:46, Rob Shakir wrote: Chris, Thanks for the clarification around the fact that MRT can be run as part of a multi-technology approach. I wouldn’t endorse such an approach operationally — why run multiple technologies alongside each other that one must understand vs. a single

Re: WGLC for draft-rtgwg-mrt-frr-architecture

entries that can result from changing the GADAG root, it is RECOMMENDED that operators prioritize for selection as GADAG root those routers that are expected to consistently remain part of the IGP topology. -Original Message- From: Stewart Bryant [mailto:stewart.bry...@gmail.com] Sent

Re: AD Review of draft-ietf-rtgwg-mrt-frr-architecture-08

+1 Stewart On 21/01/2016 12:25, Pierre Francois (pifranco) wrote: Hello everyone, I would tend to agree with Alvaro on the fact that the comparison table should completely disappear from the work. More generally, comparison with other solutions should not be present in this draft, at all.

Re: progress of draft-ietf-rtgwg-uloop-delay

On 02/03/2016 19:06, Jeff Tantsura wrote: Instead, if there are no implementations planned, we have several options. We can proceed towards publication more or less as is, with WG last call in the near future. Or we can explicitly decide to wait to publish the document, leaving it either as

Re: progress of draft-ietf-rtgwg-uloop-delay

Stephane Would some coarse increment version of incremental cost change be an appropriate compromise approach for link up? Stewart On 03/03/2016 10:57, stephane.litkow...@orange.com wrote: Hi Jeff, There is two existing implementations of the link down. Based on the feedback from my testing

Microloop protection as discussed in today's meeting

The RFC that had all of the generic methods that were known at the time of publication is RFC5715. The two phase methods were in section 6.2 (near-side) and section 6.3 (far-side). The first describing tunnelling the traffic towards the repair (and continue to use the repair), the second descr

Microloop protection as discussed in today's meeting

Appologies if this is a duplicate. The RFC that had all of the generic methods that were known at the time of publication is RFC5715. The two phase methods were in section 6.2 (near-side) and section 6.3 (far-side). The first describing tunnelling the traffic towards the repair (and continue

Re: Microloop protection as discussed in today's meeting

; connected LFA. > > One last thing, if you think that source routing can reduced to a "tunnel" we > might as well shutdown SPRING WG:) > SR in an mpls network can be viewed as a set of concatenated tunnels. The complexity is all in the naming of the tunnel end point

Re: question about draft-ietf-rtgwg-uloop-delay-02

On 20/10/2016 13:33, stephane.litkow...@orange.com wrote: Hi, Achieving link up microloop avoidance with a local mechanism is only achievable by tweaking flooding (we need to converge locally, then flood local LSP update) which was not well received by the WG, that’s why it was removed. Th

  1   2   >