Adrian Farrel | 26 Sep 14:20 2014
Picon

Adrian Farrel's Yes on charter-ietf-rtgwg-04-02: (with COMMENT)

Adrian Farrel has entered the following ballot position for
charter-ietf-rtgwg-04-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-rtgwg/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Fully support this: a good change.

I do not believe this change needs to go for external review.

Nit...
s/an optional venue/a venue/
(There is nothing in "a venue" that implies compulsion)
IETF Secretariat | 25 Sep 18:50 2014
Picon

State changed: charter-ietf-rtgwg-04-02

State changed to Internal review.

URL: http://datatracker.ietf.org/doc/charter-ietf-rtgwg/
Alvaro Retana (aretana | 23 Sep 00:55 2014
Picon

Comments on draft-ietf-rtgwg-remote-lfa

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 can either address my comments now/before the IESG gets the publication request or with any comments that come from them.

Thanks!

Alvaro.


Minor Issues
  1. 4.2.1.3 states that "In Figure 1 the intersection of the E's Q-space with S's P-space defines the set of viable repair tunnel end-points. . .there is no common node and hence no viable repair tunnel end-point."  The immediately following section (4.2.2) starts with "The mechanisms described above will identify all the possible repair tunnel end points that can be used to protect a particular link."   So..you're saying that there are no viable end-points (which is technically true because you're using the P-space)..and then you say that you figured out all the possible repair points, which is obviously not true because in the previous section you didn't mention the union of the Q-space and the extended-P-space.   All this is to say that a reader may be confused — adding mention of the extended p-space in 4.2.1.3 should clear it up.
  2. Section 5 (Example).  "When a failure occurs on the link between PE1 and P2", but the figure doesn't show these 2 routers as connected..so I'm assuming you're talking about PE1 and P1 (and later in the text PE2 and P2).
  3. Section 6.  What is the "null strategy"?  Please explain and/or clarify.
  4. Section 7.  "Ideally this is provided by the remote LFA repair target advertising this address in the IGP in use. . .out of scope for this document and must be specified in an IGP specific RFC."  What's the importance of even mentioning this here?  If the extensions don't exist and there is a mechanism that does (using the router ID, as mentioned), then why include something that doesn't exist..?  IMHO, if you want those extensions to be available, then go define them and then point back to this draft as a way to know where to establish the session.

Nits
  1. Terminology.  It would be nice to reorder this section so that terms defined later are not used to define terms earlier.  For example, P-space is used in the definition on Extended P-space.
  2. Introduction. s/many topologies[RFC6571]/many topologies [RFC6571]  (missing space)  There are several other places where the space is missing, which sort of screws up the references in the html version..maybe something that the RFC Editor will pick up on..I hope.
  3. Introduction. s/This technique describes in this document/The technique described in this document
  4. Repair Paths. s/[I-D.ietf-rtgwg-lfa-manageability].]/[I-D.ietf-rtgwg-lfa-manageability].
  5. 4.2 s/protected link S-E.,/protected link S-E,  
  6. 4.2 s/When released, tunneled packets/When released, packets (not in the tunnel anymore)
  7. 4.2.1 s/Finally we how to compute/Finally we show to compute
  8. 4.2.1 s/is provide in/is provided in
  9. 4.2.2 s/that member of the set/that the member of the set
  10. 4.3 s/pseudo-code provides/pseudo-code provided
  11. rfc3137 has been obsoleted by rfc6987
  12. 7. s/for the emote LFA/for the remote LFA
  13. Section 8.
    • I always like results in an Appendix, but that's just me..there may have been a discussion already about it (similar to the pseudo-code).
    • There are some places where some explanation could be useful: what does the fact that the PQ session could not be established mean?  What is the significance of the percentiles?  Etc..  Just to have a more complete report.
    • The last few sentences of the section propose other solutions in case the intersection between P and Q spaces is empty.  I think that is out of scope and should be taken out.  As with the suggestion of IGP extensions (section 7), if there is a specific/complete solution then it should be specified.
  14. Section 10 ends with "The following section motivates..",  but there is no such section.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alvaro Retana (aretana | 22 Sep 21:28 2014
Picon

rtgwg Rechartering

Hi!

I hope many/most of you followed the 'RTG Area Tuning' discussions over the last couple of months..and in the rtgarea meeting in Toronto.  As part of the tuning it was proposed to clarify rtgwg's charter to better explain our mission of developing work proposals that do "not yet rise to the level where a new working group is justified, yet the topic does not fit with an existing working group,
and it is either not ready for a BOF or a single BOF would not provide the time to ensure a mature proposal" (from the current charter).

To that end we have written up a new charter with the help of the ADs.  Please take a look:  http://datatracker.ietf.org/doc/charter-ietf-rtgwg/

As you read the proposed new charter, you should notice that there are 3 components to what the WG will be doing:
  1. Larger topics on demand, such as the current FRR work.  No change.
  2. Small topics (that don't fit in other WGs).  "An example of a small topic is a draft that might otherwise be AD-sponsored but which could benefit from the review and consensus that RTGWG can provide."  We have already put forth for WG consideration a couple of these (draft-ietf-rtgwg-bgp-routing-large-dc is an example).
  3. Be an "optional venue to discuss, evaluate, support and develop proposals for new work in the Routing Area".  I don't think this type of work is new to rtgwg: you may recall the energy efficiency work we discussed a few meetings ago.  But we do spend more time discussing this item on the charter.
Please send comments/question/concerns/suggestions in reply to this e-mail.

Thanks!

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
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.
Please note, however, that this will happen after the 15th of August, since I am now on holidays.

Best regards,
Georgios

________________________________________
Van: sdn [sdn-bounces <at> irtf.org] namens King, Daniel [d.king <at> lancaster.ac.uk]
Verzonden: vrijdag 25 juli 2014 20:27
Aan: 'sdn <at> irtf.org'
CC: adrian <at> olddog.co.uk
Onderwerp: [Sdn] Call for review of draft-farrkingel-pce-abno-architecture

Hi SDN RG'rs,

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

http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It has been presented in SDNRG a
couple of times.

The last call will obviously pop out sometime, but it would be nice to have review comments before then.
Perhaps you could send your comments to the authors or to the RTGWG list rather than clogging this list with
discussion of an IETF draft.

Thanks,
Dan
_______________________________________________
sdn mailing list
sdn <at> irtf.org
https://www.irtf.org/mailman/listinfo/sdn
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

Gmane