Re: [Mentoring-coordinators] draft-kompella-mpls-rmr-01 - Comments

["Ger, Javier" <[e-mail]>]

Hi Greg,

Thank you for your reply. I will be working on the questions recap and state machine using ASCII-art. I think I will be able to have them ready during next week.

On the other hand I am reading/reviewing the BFD Directed draft but until this moment I have found only minor questions/comments. I think I need more background related to RFC4379 and RFC7110, so I am trying to also read them. Anyway, if I am not able to finish these reading for next week I will send you what I have so far –in order to avoid further delays.

Thanks again.

Regards.

Javier Ger
Arquitectura y Tecnología
Gerencia Técnica | Ingeniería
Tel: (+54<Tel:(+54> 11)5530-4531
Cel: ([phone]
Hornos 690. CABA, CP C1272ACL
Argentina

De: Gregory Mirsky [mailto:[e-mail]]
Enviado el: lunes, 27 de junio de 2016 07:45 p.m.
Para: Ger, Javier <[e-mail]>; Andrés Balcabao <[e-mail]>; [e-mail]
CC: [e-mail]; [e-mail]
Asunto: RE: draft-kompella-mpls-rmr-01 - Comments

Hi Javier,
apologies for belated response. Thank you for the RMR flow-chart and the continued discussion. You’ve done great job in reviewing the RMR draft and I encourage you to sum it and send your questions and suggestions to the MPLS WG. I think that your depiction of the RMR state machine is correct. The state machine is great and would certainly benefit the document but unfortunately IETF uses what is called ASCII-art, not graphics. If you have time and patience you can convert the visio diagram into ASCII-art, i.e. use only ASCII symbols to draw boxes, lines, and etc.

                Regards,
                                Greg

From: Ger, Javier [mailto:[e-mail]]
Sent: Friday, June 10, 2016 11:41 AM
To: Gregory Mirsky; Andrés Balcabao; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: draft-kompella-mpls-rmr-01 - Comments

Hello Greg,

First of all, thank you again for your valuable feedback. I am including my comments in-line in green and tagged JG>>.

Additionally I am attaching a file with a first proposal related to state machine. I followed the draft item 4 text to derive these states and transitions. There could be some errors or miss assumptions and I have even divided states or included some extra ones in order to facilitate the understanding (things in red can be particularly disputable). In any case, as I mentioned previously, it is a first proposal and may be you or the authors can get some ideas for further phases explanation.

Regards.

Javier Ger
Arquitectura y Tecnología
Gerencia Técnica | Ingeniería
Tel: (+54<Tel:(+54> 11)5530-4531
Cel: ([phone]
Hornos 690. CABA, CP C1272ACL
Argentina

De: Gregory Mirsky [mailto:[e-mail]]
Enviado el: jueves, 09 de junio de 2016 09:21 p.m.
Para: Ger, Javier <[e-mail]<mailto:[e-mail]>>; Andrés Balcabao <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Asunto: RE: draft-kompella-mpls-rmr-01 - Comments

Hi  Javier,
thank you for very thorough review and the most excellent questions. Please find my answers in-lined and tagged GIM>>. I think that many your questions would be great for discussion on the MPLS WG list.

                Regards,
                                Greg

From: Ger, Javier [mailto:[e-mail]]
Sent: Friday, May 27, 2016 6:57 PM
To: Gregory Mirsky; Andrés Balcabao
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: draft-kompella-mpls-rmr-01 - Comments

Hello Greg,

Thanks again for your time and help. I am sending you comments related to draft-kompella-mpls-rmr-01. Apologies in advance if some question is too basic or not clear enough. Also, since Entropy Labels in SR draft is closed, I am reading the BFD draft and will share my questions during next week.

Hello Nalini, please let me know if I should remove you and mentoring coordinators from the thread or you prefer to continue in cc.

1.    Page 4 - Ring direction. It has only 2 bits. Would they be enough? or Would it be needed some additional experimental bits for future use? Are they already considered on another IGP fields (I did not read drafts related to IGP extensions for RMR).
GIM>> Indeed, there could be some type of a link that authors had not thought of yet. Given that Flags for Ring Link TLV have MBZ making the Ring Direction field into three bits seems reasonable. I’d suggest it to the MPLS list as question and proposal.
            JG>> Perfect, thank you.



2.    Page 6 – “A ring node indicates in its IGP updates the ring LSP signaling protocols it supports. This can be LDP and/or RSVP-TE. Ideally, each node should support both.”

Should not SR be also included in the scope (since it is another option for the MPLS control plane)? Or at least some mention about its future inclusion (similar to what is stated for express link in the same Page 6)?

GIM>> I think that ring protection in SR network domain would be different from RMR.
JG>> My opinion was based on that in the medium-term protection options should converge or at least be them available to any control plane, in this way it will be a design decision how to implement the features. But maybe I am misunderstanding something, sorry if that is the case.



3.    Page 7 – I get confused with the RSVP-TE “reverse call admission control” concept.

Does it mean that BW is not reserved in both directions? If so, what happen with backup or “other direction” path when traffic has to be sent through it (because current has some failure)? Can the CAC reject the request? How it works considering the LSP are multipoint, i.e. the BW is aggregate of all ring nodes that will use this LSP?

GIM>> I agree that it is underspecified. I’d suggest include this question in the list we will have after our initial discussion and send the list to the authors and the MPLS WG.
JG>> Perfect, thank you.


4.    Same page as previous comment for “counter-rotating pairs” concept.

Does it mean that there are always a pair of LSPs, one CW and second AC?

GIM>> Yes, you’re correct. This topological property of rings that guarantees protection and significantly simplifies operation is why rings are so popular, back from SONET/SDH technology.
JG>> Thank you for the explanation.


5.    Page 8 – I did not understand in depth the proposals for protections and loop avoidance. How can I get further clarification?

GIM>> We can try to discuss it step-by-step first.
JG>> Perfect, thank you.



6.    Page 11 – Similar to comment #2 for SS and SU field related to SR. Should it be signaled in the IGP?

Additionally, SS and SU have only 2 bits. Are they enough or some extra experimental bit might be needed for future use?

GIM>> I agree, adding more bit flags to SS is logical request. I understand why SU is bit-flag field but, if we are short on extra space, I’d suggest change it into value-based field.
JG>> Perfect, thank you.


7.    Page 11 – Ring Announcement Phase.

It might be needed to clarify that the MV value is not mandatory (Or is it?), and if not provisioned the lower loopback address will be taken into consideration to elect the Ring Master.

GIM>> I think that we can specify the default Mastership Value to decrease provisioning. Otherwise, MV must be explicitly provisioned. Would you agree?
JG>> Yes, I think it is a really good option. May be they can replace the following text “A node is also provisioned with a mastership value” in item 4.2 with the something like  “A node may is also be provisioned with a mastership value”. Do you think is a good suggestion?


8.    Page 11/12 – I did not understand in depth the timers (T1, T2) and how each node and all of them are going through different phases to elect the Ring Master. General concept is OK, but I think a better explanation about the sequence, including details, would be great. Perhaps a timeline containing events, timers, parameters and its values can help. A state machine is another option.

GIM>> I think that if you will draw, using ASCII-art, the state machine that would be great contribution to this draft.

JG>> I am sending an attachment with a visio graph. I would like to know your opinion, if you think this proposal is OK, I can draw it using ascii art including any suggestions from your side.



9.    Page 13 – Ring OAM.

The default hello interval for OAM protocol is defined in 3.3ms. It is not clear the reasons for this value. Furthermore, the amount of lost packets to determine a fault is not defined.

On the other hand, hello interval for the LSP is defined is one second. Again, the reasons for this value might be missing, since it does not allow sub-second reconvergence nor it is defined the number of lost packets to determine a failure.

GIM>> I think that Ring OAM is to facilitate the local protection. With interval of 3.3 ms either method guarantees link failure detection within 10 ms. This is, again, dating back from SONET/SDH technology when the protection switchover was a allotted 50 ms. Note that this is only default value and can be increased.

JG>> Thank you Greg for the explanation, now I understand better. Do not you think that should be better to specified clearly that by default 3 packets loss means fault? And that this values can be modified. Same for LSP hello packets.



10.  Additionally, as far as I understand ring direction is a parameter used by IGP to calculate path but it is not directly related to LSP direction, right? I mean, LSP is enabled to go through both ring directions but only one through a link (otherwise there would be loops).

GIM>> Yes, it is used only in the Ring Identification Phase. Once CW and AC neighbors  identified and as long as nothing changes. LSPs between the same pair of nodes are not overlapping.

JG>> Thank you for the explanation.



11.  Do you think some clarification might be needed related to overlapping with TI-LFA?

GIM>> I think that the authors outright exclude any comparison with LFA-style protection.

JG>> Thank you for the explanation. Same comments as in item 2 for my side.


12.  Minor comment. Page 2 – “it is imperative that MPLS handles rings well; this is not the case today.”

I think this sentence is very unspecific and might lead to some confusion. Today MPLS is working in different topologies, including rings, with no issues. This proposal is improving things like redundancy on MPLS layer itself, convergence time, control plane scalability, etc. but it does not mean that MPLS is working “bad”.

I think it is much more precise in Page 5 paragraph “The goals of this document …”

GIM>> I agree that the statement may be changed to something like “the ring topologies, because of their properties, can be automatically protected. MPLS doesn’t enable that today.”
JG>> Perfect, thank you.


13.  Very minor comments.

Page 9 – “In what follows, we refer to a ring node and a rink link Type-Length-Value (TLV).” rink -> ring

GIM>> In sort of archaic way we say “s/rink/ring/”
JG>> Perfect, thank you.



Page 10 - Ring ID 2 -> Ring ID 3  - 3rd Ring ID field on IS-IS Ring TLV Format

GIM>> Right, but in my copy it is p.9 in the figure. (Should suggest authors to use enumeration on figures for ease of referencing).
JG>> Perfect, thank you.

Best regards.

Javier Ger
Arquitectura y Tecnología
Gerencia Técnica | Ingeniería
Tel: (+54<Tel:(+54> 11)5530-4531
Cel: ([phone]
Hornos 690. CABA, CP C1272ACL
Argentina

De: Gregory Mirsky [mailto:[e-mail]]
Enviado el: jueves, 19 de mayo de 2016 05:31 p.m.
Para: Andrés Balcabao <[e-mail]<mailto:[e-mail]>>; Ger, Javier <[e-mail]<mailto:[e-mail]>>
CC: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Asunto: RE: Mentor Introduction: MPLS Internet Draft Review Team

Thank you, Nalini.

Hi Andres and Javier,
very good selection of the drafts:

•         RMR promises significantly simplify management of ringy MPLS topologies;

•         applicability of Entropy Label in Segment Routing been extensively discussed as part of the WG LC and the update should be coming;

•         BFD directed … I’m co-author on that. The draft is WFLC-ready but will greatly appreciate your thoughts, questions and we can have the discussion on the MPLS WG list;

•         T-LDP been, AFAIK, through WGLC and we can look through MPLS WG archive for the discussion, comments.

Please share your questions, thoughts on these or any other MPLS drafts. Will be glad to help.

                Regards,
                                Greg

From: Andrés Balcabao [mailto:[e-mail]]
Sent: Thursday, May 19, 2016 12:53 PM
To: Ger, Javier
Cc: [e-mail]<mailto:[e-mail]>; Gregory Mirsky; [e-mail]<mailto:[e-mail]>
Subject: Re: Mentor Introduction: MPLS Internet Draft Review Team

Nice to meet you Greg. It sounds perfect !!!

Regards



Andrés Balcabao
Ingeniería de Backbone IP/MPLS
Virrey Cevallos 422 | C1077AAJ | Bs As | Argentina
Teléfono: 54-11-5031-6354
IPLAN | iplan.com.ar<http://www.iplan.com.ar/>



2016-05-19 16:49 GMT-03:00 Ger, Javier <[e-mail]<mailto:[e-mail]>>:
It works for me Nalini. Thank you and thanks also to Greg.

The following are my choices (order by interest). Anyway, I am willing to start working on any draft the group decides.


•         draft-ietf-mpls-rmr-01

•         draft-ietf-mpls-spring-entropy-label-03

•         draft-ietf-mpls-bfd-directed-02

•         draft-ietf-mpls-app-aware-tldp-03

Regards.

Javier Ger
Arquitectura y Tecnología
Gerencia Técnica | Ingeniería
Tel: (+54<Tel:(+54> 11)5530-4531
Cel: ([phone]
Hornos 690. CABA, CP C1272ACL
Argentina

De: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Enviado el: jueves, 19 de mayo de 2016 04:24 p.m.
Para: Andrés Balcabao <[e-mail]<mailto:[e-mail]>>; Ger, Javier <[e-mail]<mailto:[e-mail]>>; Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
CC: [e-mail]<mailto:[e-mail]>
Asunto: Mentor Introduction: MPLS Internet Draft Review Team

Andres, Javier and Greg,

Let me introduce you.

Andres and Javier are forming an Internet Draft Review Team to study drafts in the MPLS WG.

Greg has been involved in MPLS for many years and will be able to guide you.   Thank you, Greg!

I was not able to find a Spanish speaking mentor, unfortunately!

The drafts the team is interested in are:

draft-ietf-mpls-app-aware-tldp-03
draft-ietf-mpls-rmr-01
draft-ietf-mpls-spring-entropy-label-03
draft-ietf-mpls-bfd-directed-02

How I see this proceeding is that the team will select one draft at a time to read and then find 5 questions to pose on the draft.

You may then have a webcast to discuss or do it via email.

Make sense?  Questions?

Thanks,

Nalini Elkins
IETF Mentoring Team

Inside Products, Inc.
www.insidethestack.com<http://www.insidethestack.com>
[phone]

Visite https://www.cablevisionfibertel.com.ar
__________________________________________
Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona.
Muchas gracias.
This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone.
Many thanks.
__________________________________________



________________________________

No Imprimas Digitalizá

________________________________

ESTE MENSAJE ES CONFIDENCIAL. Puede contener información amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.



THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the message nor disclose its contents to anyone. Many thanks.

Visite https://www.cablevisionfibertel.com.ar
__________________________________________
Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona.
Muchas gracias.
This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone.
Many thanks.
__________________________________________

Visite https://www.cablevisionfibertel.com.ar
__________________________________________
Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.
Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.
No debera copiar el mensaje ni divulgar su contenido a ninguna persona.
Muchas gracias.
This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.
You should not copy the messsage nor disclose its contents to anyone.
Many thanks.
__________________________________________

Visite https://www.cablevisionfibertel.com.ar<br>__________________________________________<br>
Este mensaje es confidencial. Puede contener informacion amparada por el secreto comercial.<br>Si usted ha recibido este e-mail por error, debera eliminarlo de su sistema.<br>No debera copiar el mensaje ni divulgar su contenido a ninguna persona.<br>Muchas gracias.<br>This message is confidential. It may also contain information that is privileged or not authorized to be disclosed. If you have received it by mistake, delete it from your system.<br>You should not copy the messsage nor disclose its contents to anyone.<br>Many thanks.<br>__________________________________________