The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

I have read the draft and have the following comments:


  1. It is unclear how the RNT mechanism with its FIS/FRS timers differs
     from RSVP with TE extensions. Specifically, the timers and the RNT
     mechanism resemble RSVP reservations with soft state but with
     inverted logic. This should be explained.
  2. The text does not specify via what mechanism the FIS/FRS packets
     are transmitted? Via UDP/TCP over IP, via the DCC in the SONET
     overhead using ISO CLNS? It would be nice to have some packet
     formats and outlines of transmission routines.
  3. It is pointed in the text that MPLS protection reserves bandwidth
     but the text fails to mention SONET also reserves bandwidth.
     Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually
     used for lower traffic classes.
  4. I found sect. 2.2.1 useful.
  5. Are FIS and FRS defined somewhere?
  6. Timers: There are way too many timers. I do understand that the RNT
     cuts down on the amount of notifications, but on core routers with
     large number of interfaces with large number of LSPs flowing
     through them, 8 timers per RNT is a bit much. This is sort of
     related to the question 1 above too.
  7. It seems to me that there is a lot of state associated with each
     RNT especially when the inverse forking ratio (IFR) is high. It
     would help to clearly specify exactly what state needs to be
     maintained in a list.
  8. In general, people are not concerned with the volume (bw) of
     signaling traffic but the overhead it costs in terms of processing.

In general, I found the draft of some value, but I think the RNT
mechanism should be either separated from the protection procedure or
put in an appendix.

RNT bears striking similarity to RSVP and there are already quite a
number of fields defined in RSVP-TE for the purpose of protection
switching signaling, so can we just add what is needed to RSVP-TE?

The text also omits all discussion of how restoration paths are
computed, what constraints need to be imposed, etc.

There is also a lack of specificity in the text, which I hope will
improve in a subsequent version. Ideally, an Internet draft should lend
itself to being read and then implemented unlike a research paper.

Finally, a question to the audience, how does the proposed scheme
interoperate with vendor proprieatry implementations of protection
switching? Now that the cat is out of the bag, we may want to open up
and agree on a standard.

Thanks

Bora Akyol