Re: [mpls] RtgDir review: draft-ietf-mpls-sfc-04.txt

Mach Chen <mach.chen@huawei.com> Fri, 18 January 2019 01:37 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A582126CC7; Thu, 17 Jan 2019 17:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Fe41pzkWidGu; Thu, 17 Jan 2019 17:37:33 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2642130F3F; Thu, 17 Jan 2019 17:37:32 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9354F7FFDE8F294262E6; Fri, 18 Jan 2019 01:37:30 +0000 (GMT)
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 01:37:30 +0000
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 18 Jan 2019 01:37:29 +0000
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 18 Jan 2019 01:37:29 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Fri, 18 Jan 2019 09:37:25 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-sfc.all@ietf.org" <draft-ietf-mpls-sfc.all@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mpls-sfc-04.txt
Thread-Index: AdSZOHGt85HegsS7TxCSGyYrh2LDDQLvo12AAE/hNKAAFVFcgACCf1GAAHO/mQAA/V0uAAAc/90A
Date: Fri, 18 Jan 2019 01:37:24 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927FFB98@dggeml530-mbs.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927E4EA8@dggeml530-mbs.china.huawei.com> <000901d4a53a$0e619770$2b24c650$@olddog.co.uk> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927F532A@dggeml530-mbs.china.huawei.com> <000f01d4a6ce$d8554e10$88ffea30$@olddog.co.uk> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927F9390@dggeml530-mbs.china.huawei.com> <04c801d4aaa7$d4317b60$7c947220$@olddog.co.uk> <F64C10EAA68C8044B33656FA214632C8958A02B0@MISOUT7MSGUSRDE.ITServices.sbc.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C8958A02B0@MISOUT7MSGUSRDE.ITServices.sbc.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.194.201]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/TRO0XTgHhX34vm7FzCyykQeDmHA>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-sfc-04.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 01:37:36 -0000

Hi Deborah,

I am OK with it.

Best regards,
Mach

> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
> Sent: Friday, January 18, 2019 3:46 AM
> To: adrian@olddog.co.uk; Mach Chen <mach.chen@huawei.com>;; rtg-
> ads@ietf.org
> Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-sfc.all@ietf.org
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> 
> Hi Mach,
> 
> Much thanks for your careful review!
> 
> It is always a difficult tradeoff on how much to add to a draft regarding
> terms/definitions from other RFCs. I've started IETF Last Call.
> 
> Thanks Authors!
> Deborah
> 
> 
> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk>;
> Sent: Saturday, January 12, 2019 1:51 PM
> To: 'Mach Chen' <mach.chen@huawei.com>;; rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-sfc.all@ietf.org
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> 
> Hi,
> 
> Thanks for continuing this thread. I hope that by having our discussion we can
> arrive at a solution acceptable to us both.
> 
> > I am still thinking that this may not just be an implementation
> > problem. Looking though the draft again, I feel that the draft will
> > benefit by adding more clarification text.
> >
> > For example, I found the following text (Section 6). This paragraph
> > seems the only "formal" processing rule on the SPI/SI label for the
> swapping case.
> >
> >"
> > o  When a component of the SFC system processes a packet it uses the
> >      SPI Label to identify the SFP and the SI Label to determine to
> >      which SFF or instance of an SF (an SFI) to deliver the packet.
> >      Under normal circumstances (with the exception of branching and
> >      reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the
> >      SPI Label value is preserved on all packets.  The SI Label value
> >      is modified by SFFs and through reclassification to indicate the
> >      next hop along the SFP.
> >"
> >
> > What does the component refer to (classifier, SFF  or SF) ? Can it be an SF?
> > If so, what is the processing rule?  It seems imply that the SF should
> > be SPI/SI aware, the SPI/SI cannot be swapped, popped off. Otherwise
> > the mechanisms defined in this document will not work.
> 
> But this is *exactly* the way the issue is described for the NSH.
> If the SF is NSH-aware, the NSH is not stripped and the SF processes it. If the
> SF is not NSH-aware, then a proxy strips the NSH and reimposes it after the
> SF has completed processing.
> The NSH contains the SPI which is preserved on every packet, and the SI
> which is modified as the packet progresses.
> This processing is mirrored exactly using the two MPLS labels.
> 
> > The last sentence says that "The SI Label value is modified by SFFs",
> > when does a SFF modify the SI Label value?  For example, before
> > sending the packet to an SF or after being received from an SF?  This
> > is not clear in the current draft but. The example section gives some
> > hint on this, that's one of the reasons that I think some of the
> > content should be defined as formal procedures.
> 
> Well, the full sentence is "The SI Label value is modified by SFFs and through
> reclassification to indicate the next hop along the SFP." That means that the
> SI is modified by the SFF when it needs to forward the packet to the next
> hop. And thus we must ask "what constitutes a hop in an SFC?" The answer
> to that is that each SFI is a hop, and we can follow the logic (both from RFC
> 7665 and RFC 8300, and from this draft). The packet is classified and the SFC
> header (MPLS labels or NSH) is added with SI indicating the first SF to execute.
> The packet is sent to the SFF which delivers it to the SI, then the packet is
> returned to the SFF which prepares it for the next hop (which may be
> another local or remote SFI).
> 
> That should be obvious, IMHO, to anyone familiar with RFC 7665 and RFC
> 8300. We could add some text, but I believe it is already clear with an
> understanding of SFC.
> 
> In general, I am not opposed to adding clarifications to drafts: if someone has
> a question, then it is worth making sure that subsequent readers don't have
> identical questions. But here I think we would be encroaching on the
> definitions from the SFC working group, and we shouldn't go further.
> 
> > In addition, section 8:
> >"
> >  When an SFF receives a packet containing an MPLS label stack, it
> >   checks whether it is processing an {SFP, SI} label pair for label
> >   swapping or a {context label, SFI index} label pair for label
> >   stacking.  It then selects the appropriate SFI to which to send the
> >   packet.  When it receives the packet back from the SFI, it has four
> >   cases to consider.
> >
> >   o  If the current hop requires an {SFP, SI} and the next hop requires
> >      an {SFP, SI}, it sets the SI label to the SI value of the current
> >      hop, selects an instance of the SF to be executed at the next hop,
> >      and tunnels the packet to the SFF for that SFI.
> >
> >   o  If the current hop requires an {SFP, SI} and the next hop requires
> >      a {context label, SFI label}, it pops the {SFP, SI} from the top
> >      of the MPLS label stack and tunnels the packet to the SFF
> >      indicated by the context label.
> >"
> >
> > How does an SFF determine "the current hop requires an {SFP, SI} and
> > the next hop requires an {SFP, SI}" or "the current hop requires an
> > {SFP, SI} and the next hop requires a {context label, SFI label} ?
> 
> How the devices are programmed (e.g., a control plane or management
> plane) is out of scope. So, for example, you might have some hops that use
> NSH and some that use MPLS (I'm not saying this is a good idea) and the SFF
> would need to swap between the two encodings, but how the SFF knows
> this is out of scope of this document. Draft-ietf-bess-nsh-bgp-control-plane
> provides a way of doing this, but we didn't want to require that protocol
> mechanism (much though we love this to be *the* solution).
> 
> > Should the "it sets the SI label to the SI value of the current hop,
> > selects an instance of the SF to be executed at the next hop" be
> > changed to " it selects an instance of the SF to be executed at the
> > next hop, sets the SI label to the SI value of the next hop"?
> > The SI label should be set to next hop, right?
> 
> Yes, I think you're right about that confusion. Thanks for catching it.
> 
> Best,
> Adrian
> 
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: Tuesday, January 08, 2019 5:21 AM
> > To: Mach Chen <mach.chen@huawei.com>;; rtg-ads@ietf.org
> > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-sfc.all@ietf.org
> > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> >
> > Hmmm, I think we may disagree on this ☹
> >
> > I'd ask the WG chairs and AD (especially as the review is for the
> > benefit of the
> > AD) to guide the authors.
> >
> > IMHO it is not the place of an IETF spec to tell people how to
> > implement unless the implementation changes the resultant behaviour on
> the wire.
> > From my perspective, this document tells the implementer what
> > black-box behaviour is expected: i.e. what result receiving a packet
> > should have, and what packets to generate.
> >
> > We could describe how to implement, but I can't see how that would be
> > normative. And I think there are plenty of ways to achieve the
> > required behaviour in an optimised way (for example, performing dual-
> label access).
> > We provided section 14 to give guidance that implementation using
> > existing hardware could be possible, but we didn't want to imply that
> > this was *the* way to implement.
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: Mach Chen <mach.chen@huawei.com>;
> > Sent: 07 January 2019 03:52
> > To: adrian@olddog.co.uk; rtg-ads@ietf.org
> > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-sfc.all@ietf.org
> > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> >
> > Hi Adrian,
> >
> > Thanks for your reply!
> >
> > See some response inline...
> >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > > Sent: Sunday, January 06, 2019 5:03 AM
> > > To: Mach Chen <mach.chen@huawei.com>;; rtg-ads@ietf.org
> > > Cc: rtg-dir@ietf.org; mpls@ietf.org;
> > > draft-ietf-mpls-sfc.all@ietf.org
> > > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> > >
> > > Hi Mach,
> > >
> > > Thanks for your careful review.
> > >
> > > > Minor Issues:
> > > > *	Section 13 says:
> > > > "
> > > >   b.  When the packet arrives at SFFa it strips any labels associated
> > > >       with the tunnel that runs from the classifier to SFFa.  SFFa
> > > >       examines the top labels and matches the SPI/SI to identify that
> > > >       the packet should be forwarded to SFa.  The packet is forwarded
> > > >       to SFa unmodified.
> > > >
> > > >   c.  SFa performs its designated function and returns the packet to
> > > >       SFFa.
> > > >
> > > >   d.  SFFa modifies the SI in the lower label stack entry (to 254) and
> > > >       uses the SPI/SI to look up the forwarding instructions.  It sends
> > > >       the packet with two label stack entries:
> > > >"
> > > > From above text, it seems that an SFF will have different process
> > > >for a
> > > packet that
> > > > has the same SPI/SI.
> > > >  1) if a packet is received from a previous SFF, it will match the
> > > > SPI/SI
> > > and determine
> > > >  to where the packet will be sent.
> > > >  2) if a packet is received from an SF, it will directly modify
> > > > the inner
> > > label, and then
> > > > by matching the new SPI/SI to determine to where the packet will
> > > > be
> > sent.
> > > >
> > > > Is this the intention ? If so, how does an SFF determine whether a
> > > > packet
> > > is from an
> > > > SFF or from SF?
> > >
> > > You have understood the processing correctly.
> > > In fact, the same situation exists with NSH processing: the SFF is
> > > expected to "know" whether the packet has arrived from the previous
> > > SFF
> > or from the SF.
> > >
> > > There are probably two answers:
> > > Firstly, it is entirely possible that the SFF and SF are co-resident.
> > > That is, they form part of the same implementation, possibly being
> > separated by an API.
> > > In this case, of course, the question does not arise.
> > > Secondly, it is reasonable to expect that the SFs are attached to
> > > the SFF by dedicated tunnels or ports (indeed, SFs are port-attached
> > > in the legacy service function world) so that a packet arriving on a
> > > line interface (from another SFF) is easily distinguished from one
> > > that arrives from an SF. (You might think about port-attached L3VPNs
> > > to help
> > clarity how this could work).
> >
> > If so, it's better to add some text to clarify this. Given the current
> > text, it implies that it could be determined just by matching the SPI/SI.
> >
> > >
> > > > In addition, how does an SFF apply the swap and/or pop operations
> here.
> > > E.g., when an SFF looks up the SPI,
> > > > it matches an item in a local table; what operation (swap or pop)
> > > > will
> > > apply to the SPI label? According to " The
> > > > packet is forwarded to SFa unmodified." It seems implies that
> > > > there is no
> > > any operation will be applied. If so,
> > > > this will not align with the MPLS.
> > >
> > > I think you should also look at this in the manner of a L3VPN. That
> > > is, the top label is popped to derive the context, the forwarding
> > > label is looked up within the context and swapped, and the context
> > > label is re-imposed as the packet is forwarded.
> > >
> > > Of course, there are optimisations on how an SFF might implement
> > > this, but we don't need to describe those. What we know is that the
> > > VPN-like approach can be made to work with existing PEs.
> >
> > As above, it's better to add some text to make it clearer.
> >
> > >
> > > > If the above issues exist, the " context/SF" case has the similar issues.
> > >
> > > Hope I have explained why this is not an issue.
> > >
> > > Now, we could debate why we have not made these answers more clear
> > > in the text.
> > > The first thing is that we are not trying to make any changes to the
> > > architecture used for NSH, so we did not feel we should go into
> > > explanations about how the SF/SFF relationship works.
> > > Additionally, we did not feel that (beyond the short section 14) we
> > > should tell people how to implement. The purpose of the document is
> > > to describe wire formats.
> >
> > IMHO, it may not be enough if just describing the wire formats, the
> > operations/process on the "formats" are necessary to make it an
> > implementable and interoperable protocol.
> >
> > Although Section 13 is listed as a worked example, I personally think
> > that they are necessary procedures. I'd suggest to change it to more
> "formal"
> > section, e.g., Procedures.
> >
> > Best regards,
> > Mach
> >
> > >
> > > Best,
> > > Adrian
>