Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)

"Adrian Farrel" <> Thu, 07 March 2019 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A07012798F; Thu, 7 Mar 2019 09:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HgDD6tDda-6j; Thu, 7 Mar 2019 09:26:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52ADE12798C; Thu, 7 Mar 2019 09:26:23 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x27HQKnN017857; Thu, 7 Mar 2019 17:26:20 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8E1B822040; Thu, 7 Mar 2019 17:26:20 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 78AD322032; Thu, 7 Mar 2019 17:26:20 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x27HQIjH000701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 17:26:19 GMT
From: Adrian Farrel <>
To: 'Benjamin Kaduk' <>
Cc: 'The IESG' <>,,,,
References: <> <016201d4d4f6$a91e5e10$fb5b1a30$> <>
In-Reply-To: <>
Date: Thu, 07 Mar 2019 17:26:17 -0000
Organization: Old Dog Consulting
Message-ID: <01be01d4d50a$e00ec2c0$a02c4840$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJzZtNl8vYRQS0gmn+2QKKbTlRPSgLsnwHDAkUo+M6kma+p8A==
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--17.488-10.0-31-10
X-imss-scan-details: No--17.488-10.0-31-10
X-TMASE-Result: 10--17.487700-10.000000
X-TMASE-MatchedRID: X4bcv0S75KnxIbpQ8BhdbOYAh37ZsBDCfjJOgArMOCZb8pv4L0h+ItoU RXARSc3aGUeHw8iRpB/5v5mFbneVaaf0QmPqa4kevGTc5oROod4F15s6prCIu/gnJH5vm2+gv9+ RvGSUdYD5OW6MLFs1zj7Ml2KDF54I5s2E/HDpG1lZluvuHEedhJZ6zKu0q4rtgrAXgr/AjP2XTk aFZN0PCNmCd+j0KZG8F1FkRcqUhGN2VhA+n0wGkmOho7buv7d9KsyJ61LbQNGbO/6uzMwg9CTCV wyY5KnUlcdg+0tSlGn9dLcGF3vdjeVPKBunz2ET1yMJs9mBCcWbKpAlY2y6SWsftHRGGisM4d2N auEDjqzkPRHbBrz7vxmCYyF9c9FfjtW9kIs2cSeeAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5 d3cxkNQP90fJP9eHt
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Mar 2019 17:26:26 -0000

Thanks again, Ben,


> > Section 12.2
> >
> >   Metadata Type:  The type of the metadata present.  Values for this
> >      field are taken from the "MD Types" registry maintained by IANA
> >      and defined in [RFC8300].
> >
> > The "MD Types" registry I'm finding in RFC 8300 is defined to hold
> > four-bit values; why do we need a 16-bit field to hold it here in the
> > TLV?  (I mean, "to keep the metadata itself aligned", sure, but having
> > 12 reserved bits would do that, too.)
> It's true. 
> We could have jumped either way.
> This way aligns with "normal" LTV processing.

Well, it's potentially an interop issue, now that I think about it more.
If I treat the values as integers, then I could in theory use some
little-endian encoding, or even something more strange.  So I think we
probably do need more text about resolving the mismatch (even if we don't
change the diagram).

[AF] OK. Notwithstanding that the way fields are encoded in MPLS are well
 known we will add encoding rules

> > Section 15
> >
> > I agree with the secdir reviewer that the "trusted" nature of the
> > classifier as a "trusted resource" could be further clarified.
> I am having some trouble with the subtleties here.
> I suppose this means that a trusted resource is one that will not behave in a way intended to cause harm to the network or to the payload data. That means that when a classifier puts a packet onto an SFP (by applying labels) its actions are not designed to cause the packet to avoid particular SFPs or be blackholed or be diverted to other parts of the network or SFs.
> The point here, I think, is that there is no way for the rest of the network to have any visibility into the behaviour of the classifier, but must accept packets as they are forwarded.
> Thus, the classifier is seen as within the MPLS trusted zone [RFC5920].
> If you can suggest ways we could explain that to everyone's satisfaction, then I'd be happy to add text.


It is fundamental to the SFC design that the classifier is a fully trusted
element; the classification decision process is not visible to the other
elements and its output is treated as accurate.  As such, the classifier
has (sole?) responsibility for determining the processing that the packet
will be subject to, including, for example, firewall functions.

[AF] Yes. Working with that.

> >  o  The SFC-capable devices participating in an SFC system are
> >      responsible for verifying and protecting packets and their
> >      contents as well as providing other security capabilities that
> >      might be required in the particular system.
> >
> > Do I recall correctly that we currently don't specify any mechanisms for
> > them to do so?  If so, we probably need to note that this is currently
> > in implementation-specific territory.
> I believe this quote should say "payload packets and their contents."
> Of course, a host of mechanisms exist for that, but are out of scope.

"payload packets" or "packet payloads"?  But sure, I think we're in

[AF] "Payload packets". The essence of SFC being that you have a packet stream and you send it (via an encapsulation) to be processed by SFs.

Thanks again,