[mpls] draft-kompella-mpls-rmr-01

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

Hello Authors,

I am sending you some comments and suggestions related to this draft. Apologies in advance if some of them are not clear enough, in that case please just let me know.


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? Given that Flags for Ring Link TLV have MBZ making the Ring Direction field into three bits might be an option?



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)?
My opinion is 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?


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



5.    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? Could they change into value-based field.


6.    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.

I think that we can specify the default Mastership Value to decrease provisioning. Otherwise, MV must be explicitly provisioned. Would you agree?
Additionally, you might 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 to modify the default one". Do you think is a good suggestion?


7.    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. I am attaching an state machine proposal just in case you think it can be useful for further clarification.



8.    Page 13 - Ring OAM.

The default hello interval for OAM protocol is defined in 3.3ms. Although may be that is dating back fron SONET/SDH, the reasons for this value are not specified. 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.

Do not you think that should be better to specified clearly that by default 3 packets lost means fault? And that this values can be modified. Same for LSP hello packets.



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


10.  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 ..."

Perhaps 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."


11.  Very minor comment.

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

Additionally, could it be possible to use enumeration on figures for ease of referencing.



I would like to thank Greg Mirsky for his time and guidance.

Thanks and 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


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>__________________________________________