Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD31AD0CC for ; Mon, 23 Mar 2015 11:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsuiIZlTh748 for ; Mon, 23 Mar 2015 11:17:45 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AFE1AD0AA for ; Mon, 23 Mar 2015 11:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20683; q=dns/txt; s=iport; t=1427134664; x=1428344264; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Gj3zEYCG+BXhnxhT4vVG+PYvPhi3tCDA7MA68SWHvmU=; b=fRPY2umJD9tu99GVfm7KoplqgVALCbiwD1DdlgTkCneUAH80d8qH3+c3 OZEu8tvNZmkGJiDSGHsWrYDR3pgJakZu3WnsFQngmmQq27KPVlvCGf2CJ K3V9QOILdtXDhgM5uiyY0S2F6WKT4YdJUr4GP+zM9ghLhC+bbsHRC1qXm I=; X-IronPort-AV: E=Sophos;i="5.11,453,1422921600"; d="scan'208,217";a="416656310" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Mar 2015 18:17:41 +0000 Received: from [10.61.111.170] (dhcp-10-61-111-170.cisco.com [10.61.111.170]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2NIHe2c027807; Mon, 23 Mar 2015 18:17:40 GMT Message-ID: <551058C3.6030505@cisco.com> Date: Mon, 23 Mar 2015 18:17:39 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nobo Akiya , draft-bryant-mpls-sfl-control@tools.ietf.org References: <008a01d06487$509048a0$f1b0d9e0$@gmail.com> <5510082D.5020108@cisco.com> <01c901d06576$65b7e040$3127a0c0$@gmail.com> In-Reply-To: <01c901d06576$65b7e040$3127a0c0$@gmail.com> Content-Type: multipart/alternative; boundary="------------070401060908020801020802" Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] Mail regarding draft-bryant-mpls-sfl-control X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:17:47 -0000 This is a multi-part message in MIME format. --------------070401060908020801020802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: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. > > > 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 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 > > 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070401060908020801020802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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: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.

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


-- 
For corporate legal information go to:

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