Subject: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Apr 2016 03:34:17 +0000

Hi, DT,

In the context of SFC, Dave Dolson has been discussing a packet format for a connectivity check and OAM. Dave is interested in cross-checking with other potential proposals and related pieces of work, and asked me about it.

I shared with Dave about the OOAM DR and suggested to him it would be useful for him to present and share his ideas in our DT meeting - he would very much like that.

[disclosure - I've not seen the packet formats or proposals]

Greg,

Could Dave present out our next DT meeting?

Dave,

Please do share any early material you have with this DT alias.

Thanks!

- Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 27 Apr 2016 06:02:51 +0000

Hi Carlos,
many thanks for the idea. It would be great to have Dave share thoughts about CC in SFC. I've forwarded the invitation to the next meeting to Dave.

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, April 26, 2016 8:34 PM
To: Dave Dolson; [email-masked]; Gregory Mirsky
Subject: SFC/NSH OAM for connectivity

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 27 Apr 2016 14:39:34 +0000

Thanks Carlos,
I'll give a brief description here. I can clarify if necessary.
I welcome feedback before the meeting too.

Our immediate requirement is for an SFF to health-check connected SFs at the NSH protocol layer.
(We don't find the IP-layer ping to be sufficient.)
But for standardization, we came up with something more generic, which is a next-hop echo request.
The idea is that it could be used between any "adjacent" NSH-capable elements. (SFF-to-SF, SFF-to-SFF, CF-to-SFF).

Please note this is NOT a path check; hence the SPI and SI are to be ignored. We suggest setting 0xffffff and 0xff respectively to make this clear.
(We would like this to work even if the SFF tables are empty.)

Proposal for generic OAM Connectivity Protocol (128?), which would be for adjacent NSH elements:
(Showing with MD-type 2; use MD-type 1 if you wish.)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|C|R|R|R|R|R|R|  Length=2 |  MD-type=0x2  | OAM Proto=128 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path ID=0xffffff             | SI=0xff       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OAM Sub-type                  |  OAM Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-type-specific data...
   ~

And for our Echo requirement, using sub-types 0 and 1:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|C|R|R|R|R|R|R|  Length=2 |  MD-type=0x2  | OAM Proto=128 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path ID=0xffffff             | SI=0xff       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OAM Sub-type                  |  OAM Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Query Identifier                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sequence Number                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Request timestamp seconds                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Request timestamp microseconds                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~      Variable Length Opaque Data  (optional)                  ~
   |      (Total Octets - 20) octets                               |
   |                                                   +-----------+
   |                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are:

      OAM Protocol: a value of 128 indicates the NSH header is followed
      by an OAM connectivity message.

      Service Path ID: Should be set by sender to 0xffffff; receiver
      should ignore it.

      Service Index: Should be set by sender to 255.

      OAM Sub-type:

         A value of 0 indicates echo request

         A value of 1 indicates echo response

      OAM Length: number of octets of the OAM portion of the packet.
      The minimum value for echo request/response is 20, and may be
      larger when Variable Length Opaque Data is present.

      Query Identifier is opaque to the responder; it may be used by the
      initiator to demultiplex responses.

      Sequence Number is opaque to the responder; it may be used by the
      initiator to discriminate responses from the same peer.

      The Request Timestamp Seconds and Microseconds together represent
      the time the initiator sent the packet.  It may be used for the
      initiator to determine round-trip time.  The values are defined as
      seconds and nanoseconds since the Epoch, 1970-01-01 00:00:00 +0000
      (UTC).

      Variable Length Opaque Data: the sender may put any data here.
      Data may be placed here to facilitate MTU verification.

The responder's responsibility is to echo all fields, with the exception of changing the OAM sub-type from 0 to 1.
The responder should return the response on the same transport on which it received the request.

Questions:

1.       Is there anything that already serves this purpose?

2.       If the OAM bit is set, does the NSH "Next protocol" field change to "OAM protocol"?  I.e., is it a different space?

3.       In any case, what Next Protocol value could be used for hop-by-hop? (128?)

4.       Should we create a draft?

Thanks,
-Dave

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, April 26, 2016 11:34 PM
To: Dave Dolson; [email-masked]; Gregory Mirsky
Subject: SFC/NSH OAM for connectivity

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 27 Apr 2016 21:55:51 +0000

Hi Dave,
many thanks for the details on SPI and SI values to be used for SFC OAM. Identification of OAM payload by distinct value in the Protocol field of SFC header ensures that active OAM is in-band, i.e. is fate-sharing, with the data. We've discussed format of active OAM control packets and consider using proposal from BIER Ping and Trace<https://tools.ietf.org/html/draft-kumarzheng-bier-ping-02>, where the first word of an OAM control packet (section 3.1):
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Message Type  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Message Type Dependent Data                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of the Ping packet, as proposed in the BIER document, have lots commonality with your proposal:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Echo Req/Rep  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   QTF |   RTF |   Reply mode  |  Return Code  | Return Subcode|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sender's Handle                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    TimeStamp Sent                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  TimeStamp Sent                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  TimeStamp Received                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                TimeStamp Received                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                              TLVs                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'm looking forward to discuss scope of SFC OAM, i.e. what is SFP monitoring; OAM requirements (what we need SFC Ping for), and formats.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 7:40 AM
To: Carlos Pignataro (cpignata); [email-masked]; Gregory Mirsky
Subject: RE: SFC/NSH OAM for connectivity

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, April 26, 2016 11:34 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Subject: SFC/NSH OAM for connectivity

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 14:28:06 +0000

Greg,
There are certainly many common elements, but the BIER proposal contains some BIER-isms.

    Message Type

      This document defines the following Message Types:

                   Type      Value Field
                   --------  ---------------
                     1      BIER Echo Request
                     2      BIER Echo Reply

and
    Reply mode

      The Reply mode is set to one of the below:

                   Value      Meaning
                   --------  ---------------
                     1        Do not Reply
                     2        Reply via IPv4/IPv6 UDP packet.
                     3        Reply via BIER packet

and some return codes are BIER-specific:
   The Return Code can be one of the following:

           Value      Value Meaning
           --------  ---------------
            0      No return code
            1      Malformed Echo Request received
            2      One or more of the TLVs was not understood
            3      Replying BFR is the only BFER in header Bitstring
            4      Replying BFR is one of the BFER in header Bitstring
            5      Packet-Forward-Success
            6      Invalid Multipath Info Request
            8      No matching entry in forwarding table.
            9      Set-Identifier Mismatch

and the TLVs seem generally BIER-specific.

Also (which would be a general complaint against the draft) is that the IEEE precision time format appears to be a closed standard requiring one to purchase the document.
http://standards.ieee.org/findstds/standard/1588-2008.html
- I see no reason to support anything other than the NTP time option.
- in general there are too many options, versions and protocol fields, IMHO. Contrast with ICMP.

Also, it would seem to be useful for the OAM message format to have a length field to know where the TLVs end.

My conclusion is that we could share a base protocol only if the draft-kumarzheng-bier-ping authors are willing to make some changes and refactor the document.
I would say two documents:
 1- a base OAM format (with some changes), with some generic TLVs.
2- a BIER-ping extension to the base format.

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 5:56 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 7:40 AM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Subject: RE: SFC/NSH OAM for connectivity

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 14:38:21 +0000

Also, to put things in perspective, several OAM requirements have been identified for SFC, but I'm only looking at a single-hop check at this time.
Our proposal does not attempt to check an entire path, for example.
Specifically we are trying to help an SFF (with load-balancer) detect problems with adjacent Service Functions and reachability thereof.

And I should have said that I like the idea of using TLVs vs. variable-length opaque data (which could be done with a TLV), provided the responder must echo back the entire packet (for MTU validation).

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 28 Apr 2016 17:22:29 +0000

Hi Dave,
if you can share these requirements before the meeting on Tuesday, then we can discuss how they relate to the Overlay OAM Requirements<https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00> draft. That would be very good additional topic for the meeting.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 7:38 AM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 5:56 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 20:23:44 +0000

Let me try to summarize requirements:
I'm looking for active, pro-active, bidirectional monitoring between a load-balancer and service functions with an echo-request mechanism.
I wish to perform this check multiple times per second to have an "immediate" automatic recovery.
The packet must use both directions of the data plane.
It should be possible to pipeline the messages, with multiple requests in flight at once.
The service functions are "adjacent" to the load-balancer in the overlay network.
It must be possible to check that the nodes can speak to each other at the NSH protocol layer.
I wish to be able to assert an MTU is configured properly by sending a large packet.
I wish to be able to measure round-trip time at the initiator.
The NSH packet needs to work directly on top of Ethernet.

There will be other requirements for SFC, but these define my immediate need.
I don't think there is anything difficult about defining such a protocol, just standardization.

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 1:22 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 7:38 AM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: SFC/NSH OAM for connectivity

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 28 Apr 2016 21:42:09 +0000

Hi Dave,
thank you for sharing your view on the OAM requirements.
I think that the list of OAM Requirements we compiled misses support for Path MTU Discovery. We've discussed it but opinions were split where it is common for Overlay networks as only BIER had it explicitly requested.
I'll try to map your list to requirements in the draft before the call on Tuesday.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 1:24 PM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

-Dave

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 Apr 2016 02:17:42 +0000

Many thanks Dave for sharing these details in preparation to the live discussion.

Another QQ:

If SPI/SI are ignored, what is the value on top of a vanilla ICMP-based ping? And wound’t it be better to have a reserved SPI for this function?

Thanks,

— Carlos.

> On Apr 27, 2016, at 10:39 AM, Dave Dolson <[email-masked]> wrote:
> 
> Thanks Carlos,
> I’ll give a brief description here. I can clarify if necessary.
> (We don’t find the IP-layer ping to be sufficient.)
> The idea is that it could be used between any “adjacent” NSH-capable elements. (SFF-to-SF, SFF-to-SFF, CF-to-SFF).
> 
> The responder’s responsibility is to echo all fields, with the exception of changing the OAM sub-type from 0 to 1.
> 2.       If the OAM bit is set, does the NSH “Next protocol” field change to “OAM protocol”?  I.e., is it a different space?
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> To: Dave Dolson; [email-masked] <mailto:[email-masked]>; Gregory Mirsky
> I shared with Dave about the OOAM DR and suggested to him it would be useful for him to present and share his ideas in our DT meeting — he would very much like that.
> 
> [disclosure — I’ve not seen the packet formats or proposals]
> 
> Greg,
> 
> — Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Fri, 29 Apr 2016 13:26:57 +0000

Carlos, to answer your questions,
1. The value on top of ICMP-based ping is that although ping can determine physical connectivity, it doesn’t check that the NSH protocol handler is alive.
As you know, NSH can be carried over multiple transports. So let’s say it is carried over UDP. A ping can check the IP address, but cannot determine if there is a listener on the UDP port.

2. We wish to check all SPIs, but we don’t want to send packets on all SPIs. So it would be somewhat artificial to just pick one. Also, for the echo, we DO NOT want normal SFF forwarding; we want it returned to the sender. So again, reason to ignore the path information.

Does that explain?

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 10:18 PM
To: Dave Dolson
Cc: [email-masked]; Gregory Mirsky
Subject: Re: SFC/NSH OAM for connectivity

Another QQ:

Thanks,

— Carlos.

On Apr 27, 2016, at 10:39 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

— Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 29 Apr 2016 16:57:30 +0000

Hi Dave,
got a question about bidirectional paths in SFC - e2e, segments and links. In my understanding, SFP is unidirectional even if is terminated on the ingress node. Thus, I think of the bi-directional monitoring as monitoring in forward direction and notifications in reverse. The egress may be instructed to use particular path for the reverse direction (we have similar functionality in LSP ping and for BFD over MPLS LSP). What do you think? Is my understanding close to model SFC has?

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Dave Dolson <[email-masked]>
Date: Fri, 29 Apr 2016 17:13:05 +0000

Greg,

If one needs to test a complete path then you are correct. And certainly that should be possible.
Given that paths can be uni-directional (i.e., a reverse path might not exist), this is a tricky aspect with SFC, and I think intended to be addressed by
https://tools.ietf.org/html/draft-penno-sfc-trace-03
Note that the initiator asks the receiver to send the response out-of-band to its IP address.

However, we see the next-hop availability checking as a different protocol, explicitly NOT a full path protocol.
And this is also why I proposed not using the path information fields in the echo request/repsonse.
But I'm open to using the idea of the initiator specifying the return path.

As an author of draft-penno-sfc-trace-03, perhaps Carlos could weigh in on whether that protocol could offer an in-band return-path alternative to the IP-address return method?
(As offered by the Reply-Mode of BIER Ping and Trace)

I hope this helps.

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, April 29, 2016 12:58 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 29 Apr 2016 22:10:42 +0000

Hi Dave,
thank you for the detailed explanation.
I think that we should try to have OAM toolset that can work in all scenarios whether e2e, segment or link. What we may use for the next-hop availability checking been supported in MPLS LSP ping as proxy-ping and we have added it to the OOAM Requirements:
   REQ#15: Overlay OAM MUST be able to trigger on-demand FM with
            responses being directed towards initiator of such proxy
            request.

And you've noted that "a reverse path might not exist". Is there scenario where IP network does not provide SFF reachability? What is important to keep in perspective - availability of a Source ID/address in SFC encapsulation. It not necessarily has to be IP address but an ID that can be mapped to one, e.g. like in BIER BFR ID is part of BIER encap in MPLS.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, April 29, 2016 10:13 AM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

Greg,

I hope this helps.

-Dave

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

- Carlos.