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

[Stewart Bryant <[e-mail]>]

On 23/03/2015 14:33, Nobo Akiya wrote:
>
> Hi Stewart,
>
> Thanks for the reply. Please see in-line with [NOBO].
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* March-23-15 7:34 AM
> *To:* Nobo Akiya; [e-mail]
> *Cc:* [e-mail]
> *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.
>
>
>     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.
>
> [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.
>
I would be interested in discussing this, particularly the other 
applications. I am open to evaluating alternative control protocol 
designs, preferably simple designs.

- Stewart

> Thanks!
>
> -Nobo
>
>
> - Stewart
>
>
>       
>
>       
>
>     Thanks!
>
>       
>
>     -Nobo
>
>       
>
>       
>
>     _______________________________________________
>
>     mpls mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     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
>   


-- 
For corporate legal information go to:

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