Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 11 Feb 2016 19:18:25 +0000

Dear WG:

This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as a WG document. The call for adoption will run for 2 weeks ending 2/25/2016.

Please note that this is a call for adoption, and not a last call for content of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issues you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Thanks!

SFC Chairs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 14:57:57 -0500

I am reluctant to adopt this document as it stands.
I have two related concerns, both related to the basic approach.

First, the proposal has no mechanism for tracing the service function 
forwarders.  It seems to me that in terms of OAM of service function 
paths, the service function forwarders are the critical element to be 
able to verify.

Second, it assumes that there is value in having a special aspect of the 
service functions report service function type and identity.  Given that 
this will be specialized code, it does not tell us much about the actual 
operation of the service functions.

As a lesser concern, there is a routing area design team working to pull 
together a coherent approach to OAM.  I would at least like to talk with 
them before we adopt a basic approach that may be needlessly at variance 
with other ongoing work.

Yours,
Joel

On 2/11/16 2:18 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
>
> This email serves as a call for WG adoption of draft-penno-sfc-trace-03
> as a WG document. The call for adoption will run for 2 weeks ending
> 2/25/2016.
>
> Please note that this is a call for adoption, and not a last call for
> content of the document. Adopting a WG document simply means that the WG
> will focus its efforts on that particular draft going forward, and use
> that document for resolving open issues and documenting the WG’s decisions.
>
> Please indicate whether you support adoption for not, and if not why.
> Issues you have with the current document itself can also be raised, but
> they should be raised in the context of what should be changed in the
> document going forward, rather than a pre-condition for adoption.
>
> Finally, now is also a good time to poll for knowledge of any IPR that
> applies to this draft, in line with the IPR disclosure obligations for
> WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as a document author please respond to this email (to
> the chairs) whether or not you are aware of any relevant IPR.
>
>
> Thanks!
>
>
> SFC Chairs
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 20:05:54 +0000

Hello Joel,

>paths, the service function forwarders are the critical element to be

[RP] The SFF info is present in the trace reply message. Maybe we need to
put more info?

>operation of the service functions.

[RP] I think it is basic info. An admin will know that the SF that the
packet is traversing is of proper type and actual instance. Given protocol
is extensible one has extend to include many other SF specific metrics.

>> that document for resolving open issues and documenting the WG¹s
>>decisions.
>>

---

From: Joe Clarke <[email-masked]>
Date: Thu, 11 Feb 2016 15:19:04 -0500

> as a WG document. The call for adoption will run for 2 weeks ending

I support adoption.  This is useful for troubleshooting the service plane.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 15:28:20 -0500

> [RP] The SFF info is present in the trace reply message. Maybe we need to
[JMH] What I see is that if a traceroute somehow gets to an SFF with an 
SI of the SIL, the SFF will generate a response.  The current 
understanding is that SF rather than SFF will decrement TTL.  If so, if 
the SI hits the limit, the SF will generate the response, and the packet 
won't get to the next SFF.  So I can't see when this case would ever get 
triggered.
Also, it is rather unclear how the receiver would know that a response 
was from the SFF rather than an SF.  Is there a magic SF Type for SFF?

> is extensible one has extend to include many other SF specific metrics.
[JMH}I was apparently unclear.  I am not asking for more information.  I 
am not sure that this is useful information to extract.  The actual 
configuration of this information is not related to the work the service 
function does, so there is no reason for it to be correct.  And trying 
to monitor service function operability this way seems unfortunate.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 20:47:24 +0000

The response is always from SFF because that is the entity that drops the
packet. That is precisely the situation this tool is supposed to detect.
IF the SI (even for regular data packets) is not large enough the packet
will dropped by the SFF, not SF. A packet that is decremented to SI=0 (was
1 on ingress to SF) was processed by SF and should still be sent packet to
SFF, which will then drop it.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 15:51:26 -0500

Ahh.  I had missed how you were interacting between the SF and the SFF. 
  Sorry.

Please confirm:  the idea is that the SF at the end will add its 
information, and then the SFF fronting it will send the resulting 
traceroute response?

It looks like the response is an NSH packet.  In which case it goes in 
the NSH transport.  If that transport is MPLS, for example, how will the 
receiver know who sent the response?

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 21:41:55 +0000

> On Feb 11, 2016, at 12:52 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Ahh.  I had missed how you were interacting between the SF and the SFF.  Sorry.
> 
> Please confirm:  the idea is that the SF at the end will add its information, and then the SFF fronting it will send the resulting traceroute response?

[RP] confirmed

> 
> It looks like the response is an NSH packet.  In which case it goes in the NSH transport.  If that transport is MPLS, for example, how will the receiver know who sent the response?

[RP] need to think of what kind of info can be put in the response tlv.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 11 Feb 2016 21:59:54 +0000

Reinaldo,
I also have the question about the trace report. It is to be sent to 
an IP/port, but the transport is not mentioned (that I could see).
Is it intended to be UDP?

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 11, 2016 3:51 PM
To: Reinaldo Penno (repenno); Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 22:08:06 +0000

The current implementation uses UDP because of NAT traversal. This is
something I did because at some point my SFC trace client was behind a NAT
and I wanted to get my responses back. How useful this is? Can¹t say, it
was to me. 

The draft says (I hope) that the transport used should be the same as the
one in NSH the trace request.  But I¹m open to suggestions (or more
importantly actual text) since Joel also had a questions about it.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 11 Feb 2016 22:16:53 +0000

Oh I see, you do say "The SFF will use the same encapsulation as the received packet."
I guess then the packets would traverse SFC somehow to get back?

Actually, I think it is useful to use UDP for the trace report regardless 
of the encapsulation type.
In other words, the OAM packet traverses the data plane until an
SFF acts on it, and then the report is sent over the control plane.

I think this is what you have, effectively, which is why you like the UDP.

How do you feel about that, sending the trace report over UDP regardless of the
NSH encapsulation?

-Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 17:33:10 -0500

Thinking about the return message, given that there are not always 
symmetric NSH paths, I don't think one can use NSH to carry the reply back.

Given that we can assume IP, why not remove the NSH header from the 
reply.  Instead, put a destination port number in the reply, and use UDP 
to send the reply back to the requester, no matter what the NSH 
transport is.

This has the advantage of removing any dependence of the forwared 
trace-route on the some other reverse path functioning.  And it allows 
the probing entity to use a collector which is not collocated with the 
egress of some service path.

Yours,
Joel

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 11 Feb 2016 22:35:01 +0000

Hi Dave,
I agree that sending Echo reply over IP/UDP is most practical. I don't think that we can expect SFP to be bi-directional and thus to guarantee return path based on NSH of Echo request packet. But here's the question, how responder selects destination IP address and whether destination UDP port is dynamic or assigned by IANA.

	Regards,
		Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, February 11, 2016 2:17 PM
To: Reinaldo Penno (repenno); Joel M. Halpern; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Actually, I think it is useful to use UDP for the trace report regardless of the encapsulation type.
In other words, the OAM packet traverses the data plane until an SFF acts on it, and then the report is sent over the control plane.

How do you feel about that, sending the trace report over UDP regardless of the NSH encapsulation?

-Dave

-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Thursday, February 11, 2016 5:08 PM
To: Dave Dolson; Joel M. Halpern; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

The current implementation uses UDP because of NAT traversal. This is something I did because at some point my SFC trace client was behind a NAT and I wanted to get my responses back. How useful this is? Can¹t say, it was to me. 

The draft says (I hope) that the transport used should be the same as the one in NSH the trace request.  But I¹m open to suggestions (or more importantly actual text) since Joel also had a questions about it.

On 2/11/16, 1:59 PM, "Dave Dolson" <[email-masked]> wrote:

>Reinaldo,
>I also have the question about the trace report. It is to be sent to an 
>IP/port, but the transport is not mentioned (that I could see).
>the NSH transport.  If that transport is MPLS, for example, how will 
>the receiver know who sent the response?
>
>Yours,
>Joel
>
>> The response is always from SFF because that is the entity that drops 
>>the  packet. That is precisely the situation this tool is supposed to 
>>detect.
>> IF the SI (even for regular data packets) is not large enough the 
>>packet  will dropped by the SFF, not SF. A packet that is decremented 
>>to SI=0 (was
>> 1 on ingress to SF) was processed by SF and should still be sent 
>>packet to  SFF, which will then drop it.
>>
>>
>>>>> First, the proposal has no mechanism for tracing the service 
>>>>> function forwarders.  It seems to me that in terms of OAM of 
>>>>> service function paths, the service function forwarders are the 
>>>>> critical element to be able to verify.
>>>>
>>>>
>>>> [RP] The SFF info is present in the trace reply message. Maybe we 
>>>> need to put more info?
>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with 
>>>an  SI of the SIL, the SFF will generate a response.  The current  
>>>understanding is that SF rather than SFF will decrement TTL.  If so, 
>>>if  the SI hits the limit, the SF will generate the response, and the 
>>>packet  won't get to the next SFF.  So I can't see when this case 
>>>would ever get  triggered.
>>> Also, it is rather unclear how the receiver would know that a 
>>>response  was from the SFF rather than an SF.  Is there a magic SF Type for SFF?
>>>
>>>>
>>>>>
>>>>> Second, it assumes that there is value in having a special aspect 
>>>>> of the service functions report service function type and 
>>>>> identity.  Given that this will be specialized code, it does not 
>>>>> tell us much about the actual operation of the service functions.
>>>>
>>>>
>>>> [RP] I think it is basic info. An admin will know that the SF that 
>>>>the  packet is traversing is of proper type and actual instance. 
>>>>Given  protocol  is extensible one has extend to include many other 
>>>>SF specific metrics.
>>>>
>>>configuration of this information is not related to the work the 
>>>service  function does, so there is no reason for it to be correct.  
>>>And trying  to monitor service function operability this way seems 
>>>unfortunate.
>>>
>>> Yours,
>>> Joel
>>
>>
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 22:38:47 +0000

The current draft allows for the client to specify the return IP:port so
that direct report messages are sent. The current implementation makes
full use of this.  I would get the external NAT IP:port and put int his
field. Replies would get to me across NAT, very handy, at least to me.

"Dest Port:  The trace report must be sent to this destination Port

   Dest IP:  the trace report must be sent to this destination IP
      Address”

On 2/11/16, 2:35 PM, "Gregory Mirsky" <[email-masked]> wrote:

>Hi Dave,
>I agree that sending Echo reply over IP/UDP is most practical. I don't
>think that we can expect SFP to be bi-directional and thus to guarantee
>return path based on NSH of Echo request packet. But here's the question,
>how responder selects destination IP address and whether destination UDP
>port is dynamic or assigned by IANA.
>
>	Regards,
>		Greg
>
>In other words, the OAM packet traverses the data plane until an SFF acts
>on it, and then the report is sent over the control plane.
>
>something I did because at some point my SFC trace client was behind a
>NAT and I wanted to get my responses back. How useful this is? Can¹t say,
>it was to me. 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 17:44:27 -0500

I think the problem is that the draft does not say UDP anywhere.  Since 
reverse NSH does not actually work, the draft does not currently tell 
you how to send the response.

As long as we are discussing details, some notes that do not block adoption:
I think the packet format needs a corellation ID so that responses can 
be matched to requests.
Also, I do not like trying to infer whether IPv4 or IPv6 should be used 
from the contents of the address field.  I don't care if it is padded, 
but I would like to see explicit v4 / v6 indication.

Yours,
Joel

On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote:
>>> the
>>>> service

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 11 Feb 2016 22:51:25 +0000

Right, this is something hopefully we can fix after adoption. I wasn’t
sure it would get wide support but it seems folks are happy with UDP.

In the current implementation responses are already sent over UDP as I
mentioned in other reply. But NSH header is still there (although not used
for forwarding) so that metadata, service path, index and others can be
display/debugged by client.

On 2/11/16, 2:44 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>NAT
>>>>packet
>>>>packet
>>>> to
>>>>>>>function
>>>>>>need
>>>>>> to
>>>>>an
>>>>>if
>>>>>response
>>>>>>>of

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2016 17:56:00 -0500

I think it is very hard for the reader to understand how this is
supposed to work from the current draft.

Personally, what I would like is a revised draft that addresses two issues:
1) Gives an explicit description of the theory of operation so the
reader does not have to infer it from the packet format and processing
descriptions.
2) Gives an explicit description of how replies can be returned.  It can
not be implemented inter-operably from what is in there.  I am fine with
your saying IP/UDP carrying NSH for adoption.  That may even be the
right answer.

While I would like to see the IP address family and correlation ID
issues addressed, I can live with that being dealt with after adoption.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Thu, 11 Feb 2016 23:06:00 +0000

Joel, I was actually happy to see the ipv4-mapped ipv6 address used.
It's a great way of supporting both versions without requiring an extra bit, while giving first-class status to ipv6 (it makes ipv4) the special case.

  Original Message
From: Joel M. Halpern
Sent: Thursday, February 11, 2016 5:45 PM
To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 12 Feb 2016 01:29:58 +0000

That is my thinking as well. Mapped addresses already provide explicit family and promote IPv6

> On Feb 11, 2016, at 3:05 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: Dave Dolson <[email-masked]>
Date: Fri, 12 Feb 2016 14:15:06 +0000

(Extra info)
For those not familiar with the concept, some operating systems 
support the use of IPv4-mapped-IPv6 addresses in socket application code.

Code is written for IPv6 sockets, and IPv4 also works if an
IPv4-mapped-IPv6 address is used, provided the IPV6_V6ONLY socket
option is zero.

So it's a good way to give IPv6 first-class status and also support IPv4
without separate code paths or flags.

The format is standardized in RFC4291:
https://tools.ietf.org/html/rfc4291#section-2.5.5.2

Motivation is described in section 4.2 of RFC4038:
https://tools.ietf.org/html/rfc4038#section-4.2

Both Linux and FreeBSD support this.

-Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Feb 2016 09:54:14 -0500

Looking at the descriptions you point to, those descriptions seems to 
assume that the user of the IPv4-mapped address is an IPv6-speaker, and 
that some other device will translate the packet into IPv4.

If so, that is not the same as declaring that the SFF should send an 
IPv4 message based on being told an IPv6 destination address which is an 
IPv4-mapped format address.

Is there somewhere else where that is described as a desired behavior 
for dual-stack devices?

Yours,
Joel

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Fri, 12 Feb 2016 15:42:52 +0000

Hello Joel,
Not sure if this is what you are looking for,  but 6PE, RFC 4798 (https://tools.ietf.org/html/rfc4798 ), shows an example of use of IPv4-mapped IPv6 address  on dual-stack devices.

In 6PE the IPv4 address of the egress 6PE router is encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field.  

Regards
Roberta

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, February 12, 2016 3:54 PM
To: Dave Dolson; Reinaldo Penno (repenno)
Cc: Jim Guichard (jguichar); Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Looking at the descriptions you point to, those descriptions seems to assume that the user of the IPv4-mapped address is an IPv6-speaker, and that some other device will translate the packet into IPv4.

If so, that is not the same as declaring that the SFF should send an
IPv4 message based on being told an IPv6 destination address which is an IPv4-mapped format address.

Is there somewhere else where that is described as a desired behavior for dual-stack devices?

Yours,
Joel

On 2/12/16 9:15 AM, Dave Dolson wrote:
> So it's a good way to give IPv6 first-class status and also support 
> IPv4 without separate code paths or flags.
>
>> I think the problem is that the draft does not say UDP anywhere.  
>> Since reverse NSH does not actually work, the draft does not 
>> currently tell you how to send the response.
>>
>> I think the packet format needs a corellation ID so that responses 
>> can be matched to requests.
>> Also, I do not like trying to infer whether IPv4 or IPv6 should be 
>> used from the contents of the address field.  I don't care if it is 
>> padded, but I would like to see explicit v4 / v6 indication.
>>
>> Yours,
>> Joel
>>
>>> The current implementation uses UDP because of NAT traversal. This 
>>> is something I did because at some point my SFC trace client was 
>>> behind a NAT and I wanted to get my responses back. How useful this 
>>> is? Can¹t say, it was to me.
>>>
>>> The draft says (I hope) that the transport used should be the same 
>>> as the one in NSH the trace request.  But I¹m open to suggestions 
>>> (or more importantly actual text) since Joel also had a questions about it.
>>>
>>>
>>>
>>>> I also have the question about the trace report. It is to be sent 
>>>> to an IP/port, but the transport is not mentioned (that I could see).
>>>> It looks like the response is an NSH packet.  In which case it goes 
>>>> in the NSH transport.  If that transport is MPLS, for example, how 
>>>> will the receiver know who sent the response?
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>> The response is always from SFF because that is the entity that 
>>>>> drops the packet. That is precisely the situation this tool is 
>>>>> supposed to detect.
>>>>> packet will dropped by the SFF, not SF. A packet that is 
>>>>> decremented to SI=0 (was
>>>>>>> [RP] The SFF info is present in the trace reply message. Maybe 
>>>>>>> we need to put more info?
>>>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF 
>>>>>> with an SI of the SIL, the SFF will generate a response.  The 
>>>>>> current understanding is that SF rather than SFF will decrement 
>>>>>> TTL.  If so, if the SI hits the limit, the SF will generate the 
>>>>>> response, and the packet won't get to the next SFF.  So I can't 
>>>>>> see when this case would ever get triggered.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Feb 2016 10:51:57 -0500

Thank you Roberta.
This is very close to what I am asking for, and probably close enough 
that I should shut up.
The interesting difference in that particular case is that the 6PE 
device knows that it only has an IPv4 interface in the direction in 
which it received the IPv6 address with a mapped IPv4 content.

Unless I come across a larger issue, I will accept this pointer as 
saying that the approach is sufficient, and let the matter drop.

Yours,
Joel

---

From: Georgios Karagiannis <[email-masked]>
Date: Wed, 17 Feb 2016 17:34:54 +0000

Hi Jim, Hi all,

Agree that draft-penno-sfc-trace-03 is useful since it provides several solutions for requirements identified in ietf-sfc-oam-framework.
However, as we identified in the draft-yang-sfc-trace-issue-analysis-01, see URL below, draft-penno-sfc-trace-03 describes a solution of SFC
traceroute based on NSH header, but only a subset of the requirements provided in ietf-sfc-oam-framework are addressed.

https://www.ietf.org/id/draft-yang-sfc-trace-issue-analysis-01.txt

In my opinion the draft-yang-sfc-trace-issue-analysis-01 complements the mentioned gaps in draft-penno-sfc-trace-03.

Therefore, I propose to add the provided information in draft-yang-sfc-trace-issue-analysis-01 in draft-penno-sfc-trace-03 before the latter one gets a SFC WG status.

Best regards,
Georgios

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 11, 2016 8:18 PM
To: [email-masked]
Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Dear WG:

Thanks!

SFC Chairs

---

From: Dave Dolson <[email-masked]>
Date: Wed, 17 Feb 2016 17:51:37 +0000

I support the trace approach, assuming it will be specified to work with MD-type=2 as well.
It is a simple point-solution for tracing paths.

The UDP transport needs to be clarified, but this can be easily fixed.

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 11, 2016 2:18 PM
To: [email-masked]
Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03

Dear WG:

Thanks!

SFC Chairs