Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

From: Greg Mirsky <[email-masked]>
Date: Sat, 8 Jun 2019 10:11:31 -0700

Dear Authors, Jim, Joel, et al.,
please find my comments to this draft below:

   - Section 2
      - An SFC layering model is introduced. I couldn't find it being
      mentioned in section 1.1, where the scope of the document is defined.
      - What VMx symbolize in Figure 1? To which layer of SFC they belong?
      - What is being symbolized by 'o' in Overlay network, Underlay
      network, and Link layers respectively?
      - What is the purpose of Figure 1 outside Section 2
      - what is the purpose of Section 2? For only one sentence in Section
      3 that states the obvious:

The SFC operates at the service layer.

   - Section 3
      - In "testing the service functions from any SFC-aware network
      devices (i.e.classifiers, controllers, other service nodes)", what is the
      scope of testing expected? Testing, for example, NAT? Also, what
are "other
      service nodes"? Neither RFC 7665 nor this draft define service
nodes in SFC.
      - In "validate the correlation between a Service Function Chain and
      the actual forwarding path followed by a packet matching that SFC, etc.",
      is "the actual forwarding path followed" Rendered Service Path? If it is
      so, then what is validated? That RSP is part of SFP? Also, what "etc."
      refers to? Anything else?
      - Figure 2, SF OAM. I can envision a Controller generating test
      packets for the specific SF, SF3 in the figure. But where OAM
packets come
      from for SF3 and SF5 (line interconnecting two SFs)?
   - Section 3.1.1
      - I hoped to find the definition of availability, which is a
      performance metric, and how it is measured in SFC OAM. For example, MEF
      defines Availability Performance in MEF 10.3 (it's rather
lengthy to quote
      all, so just two sentences):

Availability Performance is the percentage of time within a specified time
interval *T* during which the Frame Loss Ratio is small.

Availability Performance is based on Service Frame loss during a sequence
of consecutive small time intervals.

   - Section 3.1.2
      - It opens with "Second SFC OAM requirement ..." but I couldn't find
      where the first requirement was listed.
      - Then the text explains that the scope of performance measurement of
      a service function component is "check the loss and delay induced by a
      specific service function". Would delay variation be of interest
too? Also,
      as noted above, availability is another performance metric that
      characterizes the loss ratio over a period of time. Should it be
discussed
      in the same paragraph or this paragraph title specifically refer to loss
      and delay performance metrics since only these two metrics being
discussed?
   - Section 3.2.1
      - The text slides into the discussion of path connectivity
      verification and tracing RSPs. These are essential OAM functions but, I
      believe, are not part of measuring the availability of an SFC.
   - Section 3.3
      - Is validation of a Classifier functioning is all that is required
      in Classifier OAM? Where are Classifier performance metrics, e.g., loss
      ratio, delay, and availability?
   - Section 4
      - In the first sentence s/is/are
      - Could you kindly help me understand "which many will be applicable
      to"?
      - "Various SFC OAM requirements listed in Section 3
      <https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06#section-3>"
      I found only one explicitly called out, in Section 3.1.2. Where
are others?
      - "Many of the OAM functions at different layers are already defined
      and in existence." Could you please support this statement with
references?
      - Besides s/service/the service/ something else seems missing in the
      closing of the sentence "In order to apply such OAM functions at service
      layer, they have to be enhanced to operate a single SF/SFF to multiple
      SFs/SFFs in an SFC and also in multiple SFCs."
      - Section 4.1
      - I think that the first sentence be would be clearer if it opens
      with "Connectivity verification ..."
      - I cannot agree that "Connectivity is mainly an on-demand function".
      If that's your view, in which category you place CFM (IEEE
802.1ag)? Also,
      ping is not actual connectivity verification function as it
doesn't detect
      misconnection.
      - In the last bullet, is it suggesting to use ping as proactive CC?
   - Section 4.2
      - CC OAM, e.g., BFD, does not monitor a device but, using positioning
      statement from RFC 5880, "path between two forwarding engines, including
      interfaces, data link(s), and to the extent possible the
forwarding engines
      themselves."
      - The last bullet reads awkwardly "Notifying the failure upon failure
      detection for other OAM functions to take appropriate action." Also, can
      other applications receive failure notification?
   - Section 4.3
      - I think that the first two bullets should apply to any arbitrary
      set of SFC elements, not only to every component of the given SFC.
   - Section 4.4
      - I think that the second sentence can be improved by
      s/measurements/performance metrics/, so that it reads "These performance
      metrics could be measured pro-actively and on-demand."
      - Second para, first sentence. s/perform/measure/?
      - What the third and fourth sentences of the second para trying to
      convey? What is "approximation of packet loss"? Can you define it or give
      the reference to the definition of this performance metric?
      - The definition of a delay in SFC in the third para is confusing.
      What does it mean "delay is measured from time"? And when the second
      timestamp at the egress SFF should be taken?
      - Delay variation, I believe, is calculated, not measured.
      - What are resolution and accuracy for the delay and delay variation
      SFC PM OAM tools are required to provide, given that you expect
to measure
      them for an SF? I believe that would be very helpful to state in the
      document.
      - Also, considering the scale of measuring a delay introduced by an
      SF, what are the methods of obtaining accurate ToD?
   - Section 5.1
      - Again, regarding "connectivity" and "continuity". None of IP, MPLS
      (except MPLS-TP), or overlay OAM tools so far provides actual
connectivity
      verification. If these terms are used interchangeably in this document,
      that must be clearly stated. Alternatively, definitions of terms must be
      provided, preferably with references to well-established in the industry
      documents.
      - Information in Table 3 is outdated. With SFC WG draft on Active
      OAM, Ping and Trace columns must be set to Yes.
      - Why in Table 4 Netconf is not listed in the Notification column?
      - Assuming SF and SFC have data models and thus can be configured
      using, for example, Netconf. Why the same models cannot be used for
      orchestration? And how certain you are that there are no TOSCA models for
      orchestration?
      - What prevents an implementation of SF or SFC from generating syslog
      notification?
   - Section 6.1
      - It refers only to RFC 8300 SFC NSH. Any consideration is given
      for RFC 8595 An MPLS-Based Forwarding Plane for Service Function Chaining?
   - Section 6.2
      - RFC 5880 has no definition for "BFD reply packet". Please clarify.
   - Section 6.4.1
      - Without clear definition of the terms "SFF availability" and "SF
      availability" it is hard to agree that ICMP can be used to measure this
      performance metric (see my notes at the top).
      - "...it can be used for basic OAM functions." Could you provide the
      reference to the document that defines the list of "basic OAM functions".
      Or provide the list itself in this draft.
   - Section 6.4.2
      - Applicability of S-BFD is discussed but not of BFD, as defined in
      RFC 5880. I couldn't find the explanation for excluding BFD from
      consideration.
   - Section 6.4.3
      -    Without the definition of availability for this draft, the
      following statement is subjective, at best "In-Situ OAM could be
used with
      O bit set and perform SF availability, SFC availability of performance
      measurement."
      - Section 6.4.4
      - Clearly is missing reference to draft-ietf-sfc-multilayer-oam.
      Surprisingly, the sectin refers to the draft that expired April 2, 2016.

 After reviewing how fundamental are outstanding, in my opinion, questions,
how numerous are problems with the text and how many statements are not
supported by definitions or proper references, I believe that the document
cannot be published in its current form.

Regards,
Greg

On Tue, May 28, 2019 at 7:37 AM James Guichard <
[email-masked]> wrote:

> Dear WG:
>
>
>
> This message starts a new two week WG Last Call on advancing
> https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvBRdbjKAqYtzTUdTfB9f3Y%3D&reserved=0>
> for publication as an Informational RFC.
>
>
>
> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list. Editorial suggestions can
> be sent to the authors.  This last call will end on 11th June 2019.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 10 Jun 2019 05:10:03 +0000

Hi, Adrian,

Thank you for the review! Please see inline.

On May 31, 2019, at 5:49 PM, Adrian Farrel <[email-masked]> wrote:

Hi,

I support publication, but there are a number of minor issues.

Thanks for the support and for flagging this.

Thanks,
Adrian

===

The document has 6 front-page authors: I assume the document shepherd
will handle this with the AD.

A publication request is a good gate to handle this, indeed.

---

The RFC Editor's preferred expansion of "OAM" is "Operations,
Administration, and Maintenance" per RFC 6291.

Indeed. I can see a “comma” missing in several places since the document expands to “Operation, Administration and Maintenance". This needs fixing. Any other instances you see?

---

Requirements language should use the latest boilerplate that includes
the reference to RFC 8174.

OK/

---

Section 2

  Multiple layers come into play for implementing the SFC.  These
  include the service layer and the underlying layers (Network, Link
  etc)
Missing two periods.
s/etc)/etc.)./

OLD
  o  The service layer in Figure 1, consists of SFC data plane elements
     that includes classifiers, Service Functions (SF), Service
     Function Forwarders (SFF), SFC Proxy.  This layer uses the overlay
     network for ensuring connectivity between SFC data plane elements.
NEW
  o  The service layer in Figure 1 consists of SFC data plane elements
     that include classifiers, Service Functions (SF), Service
     Function Forwarders (SFF), and an SFC Proxy.  This layer uses the
     overlay network for ensuring connectivity between SFC data plane
     elements.
END

Ditto s/Figure 1,/Figure 1/ in all of the subsequent bullets.

Thanks for these editorials — we will fix.

---

Looking at Figure 1, I don't understand how the overlay network has more
granularity than the underlay network. Surely the "legs" in the overlay
shown between VM1-VM2 and VM2-VM3 cannot exist without "legs" in the
underlay network.

Seems like there’s a “leg” missing.

---

In each of the bullets in Section 3, you say "OAM solutions for this
component" but Section 1.1 has already said "Actual solutions and
mechanisms are outside the scope of this document."

I think you could change 1.1 to read "Details of actual solutions and
mechanisms are outside the scope of this document." But maybe it would
be better if the bullets in Section 3 were "OAM functions applicable at
this component".

Or both. I agree with this, due to overloading of the word “solution”. I like changing to “functions” and also being more specific and prescriptive on the scope.

Or you could use "OAM requirements" as in Section 3.1.1 etc.

---

Section 3

s/Below figure/Figure 2/

The arrow for "Service Function Chain OAM" is misaligned in Figure 2

Ack.

---

Section 5 does not sit easily. It is good to have a list of exist OAM
solutions that might be applicable. But by presenting it as a gap
analysis there is an implication that these solutions are to be used
for SFC OAM. That is in opposition to the statement in Section 1.1.

Maybe the way to handle this is to rebrand Section 5 as an informational
list of pre-existing OAM solutions that might be applicable to SFC OAM.
And then to state that an analysis of their applicability is for future
study.

I think an analysis of gap with existing solutions does not imply that those must be used.

However, a bit of rewording would not hurt, particularly clarifying the future study / future decision.

But then Section 6.4 is a worry because it does talk about the
applicability of solutions. That would probably mean changing the tilt
of the whole document to be "Service Function Chaining (SFC) Operation,
Administration, and Maintenance (OAM) Framework and Applicability of
Existing OAM Tools to SFC.”

The potential applicability of existing solutions is part of a framework.

---

Section 6.3 has

  The Next Protocol field in NSH header may be
  used to indicate what OAM function is it intended to or what toolset
  is used.

s/is it/is/

But (!) I think this is solution text. It is completely true that this
is one way to do it, it might even be the best way to do it, but I think
it is out of scope.

I’ll push back on this one a bit.

While it is self-dictated out of scope to define specific OAM solution and protocols, it is quite necessary to guide on a normalized way on which the potentially different OAMs may be carried and pointed to. This is not specifying what solution, but the framework on top of what solutions ride.

---

Sections 6.5, 6.6, and 6.7, need to be out-dented to 7., 8., and 9.

OK.

---

The security considerations are a little weak. In particular, isn't
there a confidentiality issue. That is, if the results of OAM can be
inspected by a third party, they can deduce a lot about the network
and the structure of the Service function Chain. Since the chains are
themselves often used for security functions, this sort of information
is sensitive.

We could list confidentiality but that would be not beyond RFC 8300 text.

---

I think [RFC0792] and [RFC4443] could afford to be Informative
References as they are used in the same way as BFD, etc.

Agreed. Let’s move.

Thanks again Adrian for the comments that, once we address and incorporate fixes, will improve the doc!

Carlos.

From: sfc <[email-masked]> On Behalf Of James Guichard
Sent: 28 May 2019 15:30
To: [email-masked]
Subject: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear WG:

This message starts a new two week WG Last Call on advancing https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ for publication as an Informational RFC.

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.  This last call will end on 11th June 2019.

Thanks!

Jim & Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 10 Jun 2019 05:10:09 +0000

Greg,

Thank you for taking the time to review this important document.

My analysis of your review is that the vast majority ((almost) all) of your comments are editorial in nature — from typos to readability suggestions. We will make updates to the document to address your comments and suggestions, and thus improve the readability of the document.

A new revision will address all the comments (all typos you called out, editorial issues and improvements, except where there’s only a personal editorial preference) as replied to below.

From the less editorial: We will also add some text to clarify "BFD applicability" and to clarity “Availability”, and all others have been responded to below including whether there were references missing (BTW we will move [ICMPv4] and [ICMPv6] as Informational as per Adrian’s comment).

Please see inline for some specific answers.

On Jun 8, 2019, at 1:11 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

  *   Section 2
     *   An SFC layering model is introduced. I couldn't find it being mentioned in section 1.1, where the scope of the document is defined.

A model is explained, not introduced. This follows the SFC models.

     *   What VMx symbolize in Figure 1? To which layer of SFC they belong?

Virtual Machine.

     *   What is being symbolized by 'o' in Overlay network, Underlay network, and Link layers respectively?

What Adrian referred to as “legs”. We will slightly update this as per Adrian’s comment.

     *   What is the purpose of Figure 1 outside Section 2

I do not understand this question.

     *   what is the purpose of Section 2? For only one sentence in Section 3 that states the obvious:

I apologize I do no follow the meaning of your note. But, S2 explains the model which is used in the doc, and “obvious” is in the eye of the beholder. Note that IETF documents have cross functional review, might not be obvious to all readers.

  *   Section 3
     *   In "testing the service functions from any SFC-aware network devices (i.e.classifiers, controllers, other service nodes)", what is the scope of testing expected? Testing, for example, NAT? Also, what are "other service nodes"? Neither RFC 7665 nor this draft define service nodes in SFC.

Good editorial point, we can change “service node” throughout the document if it makes it easier, bu RFC 8300 does use the term “service node”.

     *   In "validate the correlation between a Service Function Chain and the actual forwarding path followed by a packet matching that SFC, etc.", is "the actual forwarding path followed" Rendered Service Path? If it is so, then what is validated? That RSP is part of SFP? Also, what "etc." refers to? Anything else?

What is tested is the correlation. We can add RSP and remove the etc as editorial comments.

     *   Figure 2, SF OAM.. I can envision a Controller generating test packets for the specific SF, SF3 in the figure. But where OAM packets come from for SF3 and SF5 (line interconnecting two SFs)?

This figure is exemplary and ilustrative for highlighting the three defined components.

  *   Section 3.1.1
     *   I hoped to find the definition of availability, which is a performance metric, and how it is measured in SFC OAM. For example, MEF defines Availability Performance in MEF 10.3 (it's rather lengthy to quote all, so just two sentences):

Availability Performance is the percentage of time within a specified time interval T during which the Frame Loss Ratio is small.

Availability Performance is based on Service Frame loss during a sequence of consecutive small time intervals.

I’m not sure of the relevance of the MEF comment, but solutions can define what they measure.

If you have a specific suggestion as a replacement for “availability’, please share. However, I’ll say that “availability” is used in other RFCs as a general term.

  *   Section 3.1.2
     *   It opens with "Second SFC OAM requirement ..." but I couldn't find where the first requirement was listed.

Section 3.1.1 begins with “One SFC OAM requirement”.

     *   Then the text explains that the scope of performance measurement of a service function component is "check the loss and delay induced by a specific service function". Would delay variation be of interest too? Also, as noted above, availability is another performance metric that characterizes the loss ratio over a period of time. Should it be discussed in the same paragraph or this paragraph title specifically refer to loss and delay performance metrics since only these two metrics being discussed?

Section 3.1.1 is about availability / uptime, Section 3.1.2. about specific PM such as delay, loss.

  *   Section 3.2.1
     *   The text slides into the discussion of path connectivity verification and tracing RSPs. These are essential OAM functions but, I believe, are not part of measuring the availability of an SFC.

Only Section 3.1.1 is about availability. Section 3.2.1 is parallel to 3.1.1 and a different topic.

  *   Section 3.3
     *   Is validation of a Classifier functioning is all that is required in Classifier OAM? Where are Classifier performance metrics, e.g., loss ratio, delay, and availability?

Are there specific OAM functions on the classifier that you believe are missing? Do you believe delay in the classifier is important? Please share some text about it.

  *   Section 4
     *   In the first sentence s/is/are

Agreed. Thank you.

     *   Could you kindly help me understand "which many will be applicable to”?

Yes. Many functions applicable to many components. We can reword for ease of clarity.

     *   "Various SFC OAM requirements listed in Section 3<https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06#section-3>" I found only one explicitly called out, in Section 3.1.2. Where are others?

Section 3.1.1 for example.

     *   "Many of the OAM functions at different layers are already defined and in existence." Could you please support this statement with references?

We can do better — see Section 5.1.

     *   Besides s/service/the service/ something else seems missing in the closing of the sentence "In order to apply such OAM functions at service layer, they have to be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.”

We will fix this editorial.

  *   Section 4.1
     *   I think that the first sentence be would be clearer if it opens with "Connectivity verification …”

It would be redundant with “ function to verify"

     *   I cannot agree that "Connectivity is mainly an on-demand function". If that's your view, in which category you place CFM (IEEE 802.1ag)? Also, ping is not actual connectivity verification function as it doesn't detect misconnection.

We can change to LSP Ping.

     *   In the last bullet, is it suggesting to use ping as proactive CC?

No.

  *   Section 4.2
     *   CC OAM, e.g., BFD, does not monitor a device but, using positioning statement from RFC 5880, "path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves.”

Good point, we can remove “device"

     *   The last bullet reads awkwardly "Notifying the failure upon failure detection for other OAM functions to take appropriate action." Also, can other applications receive failure notification?

We can reword if you find it confusing.

  *   Section 4.3
     *   I think that the first two bullets should apply to any arbitrary set of SFC elements, not only to every component of the given SFC.
  *   Section 4.4
     *   I think that the second sentence can be improved by s/measurements/performance metrics/, so that it reads "These performance metrics could be measured pro-actively and on-demand."
     *   Second para, first sentence. s/perform/measure/?
     *   What the third and fourth sentences of the second para trying to convey? What is "approximation of packet loss"? Can you define it or give the reference to the definition of this performance metric?

Yes, we can make these editorial suggestions above.

     *   The definition of a delay in SFC in the third para is confusing. What does it mean "delay is measured from time"? And when the second timestamp at the egress SFF should be taken?

Can you please provide a definition?

     *   Delay variation, I believe, is calculated, not measured.

OK.

     *   What are resolution and accuracy for the delay and delay variation SFC PM OAM tools are required to provide, given that you expect to measure them for an SF? I believe that would be very helpful to state in the document.
     *   Also, considering the scale of measuring a delay introduced by an SF, what are the methods of obtaining accurate ToD?
  *   Section 5.1
     *   Again, regarding "connectivity" and "continuity".. None of IP, MPLS (except MPLS-TP), or overlay OAM tools so far provides actual connectivity verification. If these terms are used interchangeably in this document, that must be clearly stated. Alternatively, definitions of terms must be provided, preferably with references to well-established in the industry documents.

We are using IETF nomenclatures.

     *   Information in Table 3 is outdated. With SFC WG draft on Active OAM, Ping and Trace columns must be set to Yes.

No. This table covers existing OAM Functions fully defined, and/or with running code. This include OAM functions that can actually be used (normatively in documents or in practice on an actual wire).

     *   Why in Table 4 Netconf is not listed in the Notification column?

Good point! Will add.

     *   Assuming SF and SFC have data models and thus can be configured using, for example, Netconf. Why the same models cannot be used for orchestration? And how certain you are that there are no TOSCA models for orchestration?

If you know of any additional model, please share.

     *   What prevents an implementation of SF or SFC from generating syslog notification?

Someone defining it and someone coding it?

  *   Section 6.1
     *   It refers only to RFC 8300 SFC NSH.

See the last sentence of the Abstract of RFC 8300.

     *   Any consideration is given for RFC 8595 An MPLS-Based Forwarding Plane for Service Function Chaining?

Do you have any suggestion beyond the existing text that says that
   Any other overlay encapsulations used in future must have a way to
   mark the packet as OAM packet.

  *   Section 6.2
     *   RFC 5880 has no definition for "BFD reply packet". Please clarify.

Typo. Will fix.

  *   Section 6.4.1
     *   Without clear definition of the terms "SFF availability" and "SF availability" it is hard to agree that ICMP can be used to measure this performance metric (see my notes at the top).
     *   "...it can be used for basic OAM functions." Could you provide the reference to the document that defines the list of "basic OAM functions". Or provide the list itself in this draft.

We will clarify these both editorially.

  *   Section 6.4.2
     *   Applicability of S-BFD is discussed but not of BFD, as defined in RFC 5880. I couldn't find the explanation for excluding BFD from consideration.

The text already mentions BFD, but we can expand a bit.

  *   Section 6.4.3
     *      Without the definition of availability for this draft, the following statement is subjective, at best "In-Situ OAM could be used with O bit set and perform SF availability, SFC availability of performance measurement.”

See above.

  *   Section 6.4.4
     *   Clearly is missing reference to draft-ietf-sfc-multilayer-oam. Surprisingly, the sectin refers to the draft that expired April 2, 2016.

Not surprising, and not missing. See above.

 After reviewing how fundamental are outstanding, in my opinion, questions, how numerous are problems with the text and how many statements are not supported by definitions or proper references, I believe that the document cannot be published in its current form.

Thank you again for taking time to review this document. See above.

Regards,
Greg

On Tue, May 28, 2019 at 7:37 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

This message starts a new two week WG Last Call on advancing https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvBRdbjKAqYtzTUdTfB9f3Y%3D&reserved=0> for publication as an Informational RFC.

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.

Please let me know if there’s anything that was missed on this reply.

Thanks,

Carlos.

This last call will end on 11th June 2019.

Thanks!

Jim & Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc