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

[Kireeti Kompella <[e-mail]>]

Hi Javier,

Thanks for your very detailed comments! See inline for more. BTW, there is an updated version of the draft: draft-ietf-mpls-rmr-02. 

Kireeti.

> On Jul 8, 2016, at 05:33, Ger, Javier <[e-mail]> wrote:
> 
> 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?

You're right -- all possible values of these bits have been used. Two choices:
A) add a bit for ring direction. However, then it cannot be used for something else. 
B) add a bit later from MBZ when needed. A little complicated as the bits will not be contiguous, but manageable.

So, here's a suggestion: if we find a use for more bits before this becomes an RFC, we'll increase the bits. Otherwise, we'll probably leave it as is. 

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

Perhaps. 

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

Sorry, I should be clearer. In CAC, typically you set the bw of the LSP, say 6G, then keep subtracting as new services use this LSP. So, a 1G pw will reduce the available bw on the LSP to 5G. When the LSP's bw is used up, it would need to be re-signaled. 

In reverse CAC, the LSP starts with 0 bw. Every time a service uses the LSP, it has to be re-signaled with the required bw. This may seem inefficient in the control plane, but more efficient use of bw. 

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

Okay, will do. 

> I think that we can specify the default Mastership Value to decrease provisioning. Otherwise, MV must be explicitly provisioned. Would you agree?

Agreed. Default is 0. 

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

Okay. 

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

Thanks, I'll take a look. 

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

I believe this is the default for CFM and EFM. 

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

I'll specify the number of packets for both as 3. I want to keep auto-discovery simple; for other values, use configuration. 

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

No. :)  That logic means every protection draft must discuss every other protection scheme. 

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

Okay, will tweak wording. 

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

Much has changed here, but numbering figures is a good suggestion.

> 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: [phone]
> Cel: ([phone]
> Hornos 690. CABA, CP C1272ACL
> Argentina
>  
> 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.
> __________________________________________
> 
> <draft-ietf-mpls-rmr-01 (State Diagram Proposal).txt>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls