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

["Adrian Farrel" <[e-mail]>]

Thanks again, Ben,

> > COMMENT:

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

Maybe:

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

[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,
Adrian