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

Hi Stewart,

Thanks for the reply. Please see in-line with [NOBO].

From: Stewart Bryant [mailto:stbryant@cisco.com] 
Sent: March-23-15 7:34 AM
To: Nobo Akiya; draft-bryant-mpls-sfl-control@tools.ietf.org
Cc: mpls@ietf.org
Subject: 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.

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

   Where the LSP is a mulit-point to point, or multi-point to multi-
   point MPLS LSP (or other MPLS construct) the RFC6374
<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. 

[NOBO] I missed that section. From reading other sections of this document,
I was under the impression that the SFL control message will not be followed
by TLVs. Can we make this clear in section 3 and also fix up the IANA
section?

[snip]

   Value  Description                              TLV Follows Reference

   ------ ---------------------------------------- ----------- ---------

    0x0XXX SFL Control                              No          This

[snip]

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.

[NOBO] Ok.

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.

[NOBO] Right, IP-less TP becomes a special case if we were to cook up a
generic (i.e., protocol independent) TCP based OAM signaling mechanism.
However, doing this in-band of an LSP via ACH would make it more difficult
to do management of anything that's not LSP specific. For example,
management of aggregate stats label (i.e., one context label used across
multiple LSPs). I think SFL itself is very cool, but if the defined control
protocol is to handle more than SFL, then perhaps we need further
discussions.

Thanks!

-Nobo

- Stewart 

Thanks!

-Nobo

_______________________________________________
mpls mailing list
mpls@ietf.org <mailto: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