Subject: draft-chang-mpls-path-protection Comments

From: Bora Akyol <[email-masked]>
Date: Tue, 11 Apr 2000 17:53:02 -0700

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

---

From: Changcheng Huang <[email-masked]>
Date: Thu, 13 Apr 2000 11:46:43 -0500

Hi Bora,

Thank you for your comments. One particular question you have raised is
about using RSVP-TE to support the mechanism defined in this draft. This is
a very good question. We have been working on both RSVP and CR-LDP
extensions for a while. Currently we see the following problems with
RSVP-TE:

1. There are no objects defined in RSVP-TE to identify PSL, PML and a
protected path;

2. No mechanism has been provided in RSVP-TE to setup a p2mp LSP for RNT if
one carrier choose to use MPLS forwarding rather than hop-by-hop. Currently
we are thinking to use the RESV message for the request and Confirmation
message for the actual label allocation;

3. There is no notification mechanism defined in RSVP-TE to support FIS or
FRS. Currently we are thinking to use PathErr message for this purpose. It
requires changing the behavior of a RSVP node.

Therefore we are actually thinking an extension to RSVP-TE to support the
features defined in this contribution. We would like to listen to your
comments and comments from the community on this direction.

Thanks,

Chang

--
Changcheng Huang, Ph.D.
Tellabs
4951 Indiana Avenue, MS 64
Lisle, IL 60532
Tel: (630) 512-7954
Fax: (630) 512-8037

---

From: Bora Akyol <[email-masked]>
Date: Thu, 13 Apr 2000 21:21:05 -0700

See my comments within:

> 1. There are no objects defined in RSVP-TE to identify PSL, PML and a

These can be easily added.

> message for the actual label allocation;

Much better to carry the RNT using IP.

> comments and comments from the community on this direction.

As I said before, it is easier to extend RSVP-TE then write yet another
protocol.

Regards

Bora