[mpls] Mail regarding draft-bryant-mpls-sfl-control

["Nobo Akiya" <[e-mail]>]

Hi Authors,

This proposal is very much needed to use PM for wider range of scenario, and
the method to achieve this w/o increasing the label stack size for
application labels is very clever! I read through the document (along with
draft-bryant-mpls-synonymous-flow-labels) and had few questions which I hope
you can clarify.

1) Shouldn't the SFL control message contain a source (i.e., requester)
identifier field? Without that, session-ID/SFL-Batch can collide amongst
multiple sources for a same FEC (e.g., mp2p), creating confusion to the
receiver.

2) Is there is any use case for the SFL "request" operation needing to be
processed on a non-egress LSR (i.e., transit LSRs)? If there is no such use
case, it might be a good idea to restrict the processing of the "request"
operation by the egress of the FEC described in the control message, in case
such packets prematurely terminate. Thoughts?

3) When I thought about this topic a while back, my thought at the time was
to use some sort of a TCP connection between the 2 nodes to send control
messages to allocate/maintain context labels. What was the design decision
which lead up to preferring the ACH to send the SFL control messages (as
opposed to a TCP connection)?

Thanks!

-Nobo