Carlos,
Looks good on all but one point - I think I see why you're referencing
GTSM, since packets at the SFC layer would generally be one hop away
from each other at that layer. Is that correct? However, I really don't
have sufficient experience with GTSM to craft specific text. If you
think it's important enough to include, could you propose some text for
me to include?
Thanks again,
Andy
On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata)
<cpignata@xxxxxxxxx <mailto:cpignata@xxxxxxxxx>> wrote:
Hi, Andy,
On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <agmalis@xxxxxxxxx
<mailto:agmalis@xxxxxxxxx>> wrote:
Carlos,
Many thanks for your review! I'm also including the SFC WG on my
reply.
Thanks for the quick response, and for considering the comments!
I enjoyed reading this document — please see below.
Comments inline.
On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro
<cpignata@xxxxxxxxx <mailto:cpignata@xxxxxxxxx>> wrote:
Reviewer: Carlos Pignataro
Review result: Has Issues
Reviewer: Carlos Pignataro
Review Result: Has Issues
I have reviewed this document as part of the Operational
directorate's
ongoing effort to review all IETF documents being processed by
the IESG. These
comments were written with the intent of improving the
operational aspects of
the IETF drafts. Comments that are not addressed in last call
may be included
in AD reviews during the IESG review. Document editors and WG
chairs should
treat these comments just like any other last call comments.
This document is highly readable, includes very clear textual
descriptions, and
is very well organized. Easy to read in its simplicity.
However, it would
benefit from a more explicit connection to the transport encap
mechanics from
RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding
a Figure or an
SFF NSH Mapping Table example, to depict and/or exemplify the
SFF function.
I'm trying to envision what would make a good figure here. We
could add an additional line to Table 1 of RFC 8300 and reference
that table:
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 25 | 220 | Label 5467 | MPLS |
+------+------+---------------------+-------------------------+
Is that what you had in mind? If not, I'm open to other suggestions.
If you think it helps, this would be a good addition.
>From an Operational standpoint, the document seems largely
appropriate in terms
of dataplane considerations. Some key considerations are
explicitly out of
scope:
The method used by the downstream receiving node to
advertise SFF
Labels to the upstream sending node is out of scope of this
document.
This really seems to mean that, with the simple definition in this
Informational document, interoperable implementations cannot
yet exist. If
there is no mechanism to advertise the SFF Label or to manage
the semantics of
this particular label, how will it know? Static configuration,
which is not
covered anyway, is not in my humble opinion a manageable
scalable approach.
Actually, while it is outside the scope of this document, it is
within the scope of draft-ietf-bess-nsh-bgp-control-plane, and
text is being added to the next revision of that draft to show how
it can be used to signal the encapsulation defined here. This was
worked out after this draft was forwarded to the IESG, but we can
now add a reference to that draft seeing as we'll be doing a
post-last-call update.
I think that will help, as an Informative “one embodiment” type of link.
Title: MPLS Encapsulation For The SFC NSH
RFC 8300 makes an explicit distinction between the terms
'encapsulation' and
'transport encapsulation' (see e.g., Figure 1, Section 1.5 5.,
and Section 4 of
RFC 8300).
It seems to me that this is the "MPLS Transport Encapsulation
for the SFC NSH"
Thanks, we'll fix that.
2. MPLS Encapsulation Using an SFF Label
Similarly, "2. MPLS Transport Encapsulation Using an SFF Label"
The encapsulation is a standard MPLS label stack [RFC3032]
with an
SFF Label at the bottom of the stack, followed by a NSH as
defined by
[RFC8300] and the NSH payload.
Insteadf of "NSH payload" I think "orignal packet" is meant.
RFC 8300 uses both "payload" and "original packet/frame", but the
latter more than the former. So we can change "payload" to
"original packet/frame".
Also, this encapsulation is Underdefined: What is the value of
TTL? TC?
I've been looking back at other related RFCs (such as PW and IP
VPN label definitions) and they're also mostly silent on these
values. I did find the following in RFC 6073:
The setting of the TTL of the PW MPLS
label is a matter of local policy on the originating PE, but SHOULD
be set to 255.
Regarding the TC, we can follow the example of RFC 6391:
This document does not define a use for the Traffic Class (TC) field
[RFC5462 <https://tools.ietf.org/html/rfc5462>] (formerly known as the Experimental Use (EXP) bits
[RFC3032 <https://tools.ietf.org/html/rfc3032>]) in the flow label. Future documents may define a use for
these bits; therefore, implementations conforming to this
specification MUST set the TC field to zero at the ingress and MUST
ignore them at the egress.
Do you have any alternative suggestions?
These two approaches sounds good to me. And Ack to the other
previous responses.
Much like a pseudowire label, an SFF Label is allocated by the
downstream receiver of the NSH from its per-platform label
space.
A PW Label is more restrictive. RFC 8077 says it MUST be
allocated as
per-platform:
egress LSR only. Note that the PW label must always be at
the bottom
of the packet's label stack, and labels MUST be allocated
from the
per-platform label space.
Is this the case for the SFF Label as well? If so, what is the
implication of
the MUST? If not, why is it different than other equivalent
similar labels?
We can change the text to:
Much like a pseudowire label, an SFF Label MUST be allocated by
the downstream receiver of the NSH from its per-platform label
space, since the meaning of the label is identical independent of
which incoming interface it is received [RFC3031].
That’s a great improvement.
2. Push the SFF Label to identify the desired SFF in the
receiving
MPLS node.
TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.
As I noted above, 255, although I used RFC 6073 as my source
rather than 5082. We'll add that here as well.
Sounds good.
These protocols use 5082 in one form or another:
https://datatracker.ietf.org/doc/rfc5082/referencedby/
4. Operations, Administration, and Maintenance (OAM)
Considerations
OAM at the SFC Layer is handled by SFC-defined mechanisms
[RFC8300].
However, OAM may be required at the MPLS transport layer.
If so,
then standard MPLS-layer OAM mechanisms such as the Generic
Associated Channel [RFC5586] label may be used.
RFC 5586 is _not_ an OAM mechanism. It is an associated
channel creation
mechanism, over which OAM could be carried.
Thus, what traditional MPLS OAM can be carried here? Things
like RFC 4379 / RFC
8029 would need the definition of an SFF Label FEC (which does
not exist).
Which other one? IP/ICMP seems of very limited value.
That's a good point about RFC 5586. The intention is that the MPLS
OAM would be at the transport label layer above the SFF label, so
most any MPLS-layer OAM would be applicable. So how about
rewording to make that more clear:
OAM at the SFC Layer is handled by SFC-defined mechanisms
[RFC8300]. However, OAM may be required at the MPLS transport
layer. If so, then standard MPLS-layer OAM mechanisms may be used
at the transport label layer (the labels above the SFF label).
Looks good to me, thank you.
6. Security Considerations
Have you considered the use of GTSM?
No, we hadn't. Can you point me to any examples of GTSM being used
in an MPLS or PW context?
Yes, see above.
8. References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service
Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665
<https://www..rfc-editor.org/info/rfc7665>>.
SHould RFC 7665 be Normative? It defines the "SFF" which is
quite central to
understanding this document.
Good point. It was there because 7665 is an Informational RFC, but
RFC 8067 does allow normative references to informational RFCs, so
I'll move it.
Thank you.
Other Nits and Editorials:
SFF Labels are similar to other service labels at the
bottom of an
MPLS label stack that denote the contents of the MPLS
payload being
other than IP, such as a layer 2 pseudowire, an IP packet
that is
routed in a VPN context with a private address, or an Ethernet
virtual private wire service.
This says "being other than IP, such as IP", which seems to be
self-contradictory :-)
:-)
How about we change "other than IP," to "other than a normally
routed IP packet”,
That would disambiguate it.
Thanks again.
To me, the control plane / advertisement was the most important
operationally-relevant comment.
Thanks,
Carlos.
Thanks again,
Andy
