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

On 22/03/2015 10:02, Nobo Akiya wrote:
> 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.


    4
    <https://tools.ietf.org/html/draft-bryant-mpls-sfl-control-00#section-4>.
    Return Path


    Where the LSP is a mulit-point to point, or multi-point to multi-
    point MPLS LSP (or other MPLS construct) theRFC6374  <https://tools.ietf.org/html/rfc6374>  Address TLV MUST
    be included in Query packet, even if the response is requested in-
    band, since this is needed to provide the necessary return address
    for this request.

So I think we have that covered.
>
> 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?
The work is written up as operating between LSP endoints, but you could
run it at a midpoint where the label becomes top of stack - i.e. at
any point on an LSP or at a PW stitching point. You would need to run the
setup between the two adjacent mid-point nodes but that is possible.
>
> 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)?
There were two reasons for doing this, one that we wanted to make this
independent of the label protocol so we did not need to do this for LDP,
RSVP, BGP, MPLS-TP etc, and the best way seemed to be a common
protocol that run under the main signalling protocols and operated in
all of these environments. Secondly I wanted the same solution for
MPLS and MPLS-TP. This seemed to be a way to achieve these objectives.

- Stewart

>
> Thanks!
>
> -Nobo
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html