karagian | 31 Aug 09:35 2014
Picon
Picon
Picon

RE: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture


Hi Dan, Hi Adrian,

Sorry for the delay on sending my comments on the draft-farrkingel-pce-abno-architecture-10
I have seen that you have updated the draft and that you have now published version 11.

Please note that IMHO, the below comments apply also to version 11 of this draft:

First of all I would like to mention that the draft is useful for the IETF and that its IETF publication
process can start soon.

Comment_1: Please emphasize how the ABNO architecture can be applied in the context of SFC (Service
Function Chaining). In other words what is the relation between the IETF SFC WG documents and this document.

Comment_2: The draft is not describing in detail which existing northbound interface solutions can be
used in combination with the ABNO architecture. Please emphasize what are the existing IETF activities
that can be used/applied for the support of the northbound interface.

Best regards,
Georgios
________________________________________
Van: sdn <sdn-bounces <at> irtf.org> namens karagian <at> cs.utwente.nl <karagian <at> cs.utwente.nl>
Verzonden: vrijdag 1 augustus 2014 09:19
Aan: d.king <at> lancaster.ac.uk; sdn <at> irtf.org
CC: adrian <at> olddog.co.uk
Onderwerp: Re: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Hi Dan,

Please note that I have read the draft and I am willing to send comments to the  RTGWG list.
(Continue reading)

Alia Atlas | 26 Aug 23:16 2014
Picon

Just interesting FYI - liaison from IEEE referring to MRT work

For those interested in seeing some additional uses of MRT, there's a liaison
from IEEE to the PCE and ISIS WG below that includes a contribution using it.

https://datatracker.ietf.org/liaison/1345/

Regards,
Alia
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alvaro Retana (aretana | 7 Aug 16:33 2014
Picon

IPR Claims related to draft-lapukhov-bgp-routing-large-dc

Hi!

There seems to be good support and interest in the WG to adopt this draft.

I want to formally ask the authors (no additional contributors are listed in the latest version of the draft) to please respond to this message indicating whether or not you are aware of any relevant IPR.  The draft will not be adopted until we have received a response from each author.

Thanks!

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
stephane.litkowski | 1 Aug 09:52 2014

WG adoption request for draft-litkowski-rtgwg-spf-uloop-pb-statement / draft-decraene-rtgwg-backoff-algo

Dear all,

 

Following the two presentations in Toronto, the fruitful discussions in the meeting, the hallways and on the mailing list we’d like to request WG adoption of

15:30-15:40 - draft-litkowski-rtgwg-spf-uloop-pb-statement

15:40-15:50 - draft-decraene-rtgwg-backoff-algo

 

Thanks,

Best regards,

Stéphane, Bruno

 

 

 

_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Acee Lindem (acee | 29 Jul 23:45 2014
Picon

Generic Fault-avoidance Routing Protocol for Data Center Networks - draft-sl-rtgwg-far-dcn-01

I believe this document needs some significant revision before it is considered or even presented again. Rather then spending 8 pages listing comparing FAR to some naïve OSPF implementation and claiming that it solves all the attendant routing problems, you should start the draft with an overview of the protocol and including some concrete arguments as to why it scales better than existing IGPs. Then you need to provide a more detailed description of how the protocol works. It is not apparent from the text and there are a number of unanswered questions. For example, if flooding is unreliable, how do you know reachability and failures are propagated? What constitutes a “regular topology”? 

Thanks,
Acee


_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Acee Lindem (acee | 29 Jul 22:38 2014
Picon

draft-litkowski-rtgwg-spf-uloop-pb-statement-00

I support this work. While all the anecdotal discussion is interesting and no one should think this will eliminate uloops, I agree with Stephane that having a common algorithm and common scheduling parameters will mitigate uloops due to different algorithm and parameters. Vendors could continue to support the existing algorithm by default. 
Thanks,
Acee 
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Jeff Tantsura | 29 Jul 18:41 2014
Picon

http://www.ietf.org/proceedings/90/minutes/minutes-90-rtgarea

Hi,

Please find the minutes at
http://www.ietf.org/proceedings/90/minutes/minutes-90-rtgarea.

Thanks to Acee Lindem for taking the notes!

Cheers,
Jeff
Petr Lapukhov | 27 Jul 19:30 2014

WG review for draft-lapukhov-bgp-routing-large-dc

Hi,

Authors of draft-lapukhov-bgp-routing-large-dc would like to submit it for WG review and possible
adoption as a workgroup document. In this draft we summarize our experience of using BGP as the only
protocol for routing in large-scale data-center networks (100K+ bare metal servers, multiple
thousands of routers). 

Document location: http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc/

Thank you!

Petr
Adrian Farrel | 25 Jul 19:57 2014
Picon

Call for review draft-farrkingel-pce-abno-architecture

Hi,

The authors of draft-farrkingel-pce-abno-architecture are in the process of
requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It
spans quite a lot of IETF technology.

The last call will obviously pop out sometime, but it would be nice to have
review comments before then.

Thanks,
Adrian
Antoni Przygienda | 24 Jul 23:05 2014
Picon

MINIMIZE BACKOFF SPF two technical points

As first, I’m supportive for the work & I think it’s of solid applicable value albeit it’s strictly not IETF territory (it’s not necessary for interop strictly speaking).

 

First is very blunt:  if you manage to really make all the routers in the area compute <at> precisely the same time, you may not be doing yourself the favor you seek ;-)  What I mean is that generating perfectly synchronized peaks in a network tends to generate strange attractors, a good example was the synchronization of the HELLOs on all links over time that had to be jittered. Peaks can stress infra unexpectedly & lead to e.g. synchronized re-advertisement of LSAs  (or anything that SPF can trigger now and in the future).  Given on top that an SPF in the future is not necessarily the 2-3 msec SPF seen today (rLFA & such runs seem to become the new flavor of SPF) I suggest to include a small configurable jitter before the first SPF is triggered (couple msecs should do the trick but I’m willing to hear the argument that flooding de-sync’s the SPF runs enough already).

 

The other issue is far more subtle but may merit a section in the draft.  This work is pushing the protocol in a very specific direction along the CAP paradigm, i.e. a link-state routing protocol is roughly

 

1.      Always 100% P (partitioned)

2.      Basically 100% available  A  (tad hard to define given FIBs)

3.      _eventually_ consistent C

 

Now, it is fairly well understood that having all 3 is not possible across very wide set of CS problems and we are not exempt of that.  We cannot move P  so pushing on the C will cause A to move to the negative. Now, what do I mean by that.  Triggering the SPFs more aggressively will give you better consistent&available in the scenario of a single link failure if things go well. Now, compared to e.g. a batching algorithm that computes every 500 msecs without backing off and will show linear consistent&available even in case of fast-link flapping, many links failing consecutively and so on, exponential backoff will cause massively lower consistency after several link failure and this network-wide so certain people may loose big time when using that. Beside that, the quick SPFs can block lots of other things in the protocol that are not parallelized or block other protocols waiting for SPFs to finish or next SPF (2nd failure) stuck on FIB download running (all hypothetical, but availability in widest sense will go down if you see more consistency). Again, the work is good but the section will show people that it’s not an ‘universal’ improvement but something triggered to ideally a seldom occurring 1 or 2 links failure.

 

Thanks

 

--- tony

 

 

 

“FUTURE, n.
That period of time in which our affairs prosper, our friends are true and our happiness is assured.”
Ambrose Bierce, The Unabridged Devil's Dictionary

 

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Hannes Gredler | 24 Jul 14:35 2014
Picon

On minimizing SPF backoff induced blackouts

hi RTGWG,

some old presentation from Dave Katz on backoff and timing.
https://www.nanog.org/meetings/nanog25/presentations/katz.ppt
    [courtesy Chris Bowers for digging it up ...]

slide 15 is of particular interest - says that if
an implementation and the system around it is properly
designed then no backoff should be required.

/hannes

Gmane