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

From: "Nobo Akiya" <[email-masked]>
Date: Sun, 22 Mar 2015 05:02:31 -0500

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Mar 2015 12:33:49 +0000

> multiple sources for a same FEC (e.g., mp2p), creating confusion to the

    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.
> 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.
> 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
> [email-masked]
> 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

---

From: "Nobo Akiya" <[email-masked]>
Date: Mon, 23 Mar 2015 09:33:55 -0500

Hi Stewart,

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

From: Stewart Bryant [mailto:[email-masked]] 
Sent: March-23-15 7:34 AM
To: Nobo Akiya; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Mail regarding draft-bryant-mpls-sfl-control

Hi Authors,

 <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.

[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]

[NOBO] Ok.

[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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Mar 2015 18:17:39 +0000

On 23/03/2015 14:33, Nobo Akiya wrote:
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* March-23-15 7:34 AM
> *To:* Nobo Akiya; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Mail regarding draft-bryant-mpls-sfl-control
>
> [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]
>
>       
>
>       
>
> [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