Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

From: <[email-masked]>
Date: Wed, 24 Apr 2019 12:12:41 +0000

Hi authors, WG,

This document has been accepted as a new WG document.

Authors, please:

-          update email address of authors

-          republish current/same draft (reviewed and accepted by the WG) as draft-ietf-spring-srv6-network-programming-00

-          publish -01 to reflect comments and agreement made on the mailing list

-          reply to unanswered WG comments and engage resolution on open points raised so far, in particular during WG adoption call. E.g. (1), (2)

As an additional point, this document is not intended to update RFC 8200. If a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in the 6MAN WG and normatively referenced.

Thank you,
--Bruno, Rob

(1)    https://mailarchive.ietf.org/arch/msg/spring/ulYVHKfb6h4fOtM8kqLmeGnVNlY

(2)    https://mailarchive.ietf.org/arch/msg/spring/G_1ZqvInpZ9N2TX7TK8zOLa-e9I

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 13, 2019 7:50 PM
To: SPRING WG
Cc: [email-masked]
Subject: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

Hi SPRING WG,

This email initiates a three week call for working group adoption for draft-filsfils-spring-srv6-network-programming. (Three weeks to account for the IETF week)

Please indicate your support, comments, or objection, for adopting this draft as a working group item by April, 3rd, 2019 (aka 2019-04-03)

We are particularly interested in hearing from working group members that are not co-authors of this draft.

We are also looking for volunteers who would be ready to perform a technical review of this work at some later stage, such as before or during WG the last call.

In parallel to this adoption call, I will send an IPR call for this document. We will need all authors and contributors to confirm their IPR position on this document.

There is currently 1 IPR filled (2)

(1)  https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07

(2)  https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming&submit=draft

Thank you,

--Bruno & Rob.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Apr 2019 10:41:11 +0100

Hi chairs,

I hate to sound like a broken record. I just want to get this issue
clarified before we get to a late stage and risk being forced to start
again.

RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291
has a somewhat simplistic and possibly historic definition of an IPv6
address.

   IPv6 addresses are 128-bit identifiers for interfaces and sets of

   interfaces (where "interface" is as defined in Section 2 of [IPV6]).

.where the reference was to RFC 2460 which (of course) is obsoleted by RFC
8200. RFC 8200 has.

   interface    a node's attachment to a link.

   address      an IPv6-layer identifier for an interface or a set of

                interfaces.

Now, during the adoption poll, I suggested that the chairs might like to
ping 6man to check that the proposed work in this draft is an acceptable
modification to this definition.

The challenge, as far as I see it, is purely semantic. That is, we propose
to place in the DA field of an IPv6 header a value which is routable but
which does not identify an interface. 

I am not clear whether this represents an Update to RFC 8200 or to RFC 4291,
but I do strongly recommend that the chairs check with 6man that this
approach is not going to be rejected during IETF last call.

Thanks,

Adrian

From: spring <[email-masked]> On Behalf Of
[email-masked]
Sent: 24 April 2019 13:13
To: SPRING WG <[email-masked]>;
[email-masked]
Subject: Re: [spring] Working Group Adoption Call for
draft-filsfils-spring-srv6-network-programming

Hi authors, WG,

Authors, please:

*	update email address of authors
*	republish current/same draft (reviewed and accepted by the WG) as
draft-ietf-spring-srv6-network-programming-00
*	publish -01 to reflect comments and agreement made on the mailing
list
*	reply to unanswered WG comments and engage resolution on open points
raised so far, in particular during WG adoption call. E.g. (1), (2)

As an additional point, this document is not intended to update RFC 8200. If
a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in
the 6MAN WG and normatively referenced.

Thank you,

--Bruno, Rob

1.
https://mailarchive.ietf.org/arch/msg/spring/ulYVHKfb6h4fOtM8kqLmeGnVNlY
2.
https://mailarchive.ietf.org/arch/msg/spring/G_1ZqvInpZ9N2TX7TK8zOLa-e9I

From: spring [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 13, 2019 7:50 PM
To: SPRING WG
Cc: [email-masked]
Subject: [spring] Working Group Adoption Call for
draft-filsfils-spring-srv6-network-programming

Hi SPRING WG,
 
This email initiates a three week call for working group adoption for
draft-filsfils-spring-srv6-network-programming. (Three weeks to account for
the IETF week)
 
Please indicate your support, comments, or objection, for adopting this
draft as a working group item by April, 3rd, 2019 (aka 2019-04-03)
We are particularly interested in hearing from working group members that
are not co-authors of this draft.
 
We are also looking for volunteers who would be ready to perform a technical
review of this work at some later stage, such as before or during WG the
last call.
 
In parallel to this adoption call, I will send an IPR call for this
document. We will need all authors and contributors to confirm their IPR
position on this document.
There is currently 1 IPR filled (2)
 
(1)
<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-
07>
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-0
7
(2)
<https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-netw
ork-programming&submit=draft>
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-netwo
rk-programming&submit=draft

Thank you,
--Bruno & Rob.

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Apr 2019 16:48:23 +0200

Hi Adrian,

I think you are on a very slippery slope here :) Hope you are double
diamond skier !

With point you are making here you are questioning encoding of any
information in the last octets of IPv6 address as it does not meet
definition of the interface address.

Well for one let's observe that interface can be both physical and logical
entity and as such especially being a logical one can be tight with a
service switching vector in any network element. So even based on all IPv6
related RFCs you have quoted it does not violate any.

Then in one shot you are dismissing sound project like TeraStream or even
recent pretty interesting proposals
like draft-li-6man-service-aware-ipv6-network. And if you look at 6man list
you see that there was some discussion about this draft and no one
questioned the point of potential "abuse" of semantics of IPv6 address as
such.

Therefor till that happens I think there is nothing blocking SPRING to
proceed with adoption of draft-filsfils-spring-srv6-network-programming.

Best,
Robert.

On Sat, Apr 27, 2019 at 11:41 AM Adrian Farrel <[email-masked]> wrote:

> RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC
> 4291 has a somewhat simplistic and possibly historic definition of an IPv6
> address…
>
> …where the reference was to RFC 2460 which (of course) is obsoleted by RFC
> 8200. RFC 8200 has…
>
> I am not clear whether this represents an Update to RFC 8200 or to RFC
> 4291, but I do strongly recommend that the chairs check with 6man that this
> *From:* spring <[email-masked]> *On Behalf Of *
> *Sent:* 24 April 2019 13:13
> *To:* SPRING WG <[email-masked]>;
> *Subject:* Re: [spring] Working Group Adoption Call for
>    - republish current/same draft (reviewed and accepted by the WG) as
>    - reply to unanswered WG comments and engage resolution on open points
> As an additional point, this document is not intended to update RFC 8200.
> If a behavior needs to update RFC 8200, it should be defined in a 6MAN
> draft in the 6MAN WG and normatively referenced.
>
>
>
> Thank you,
>
> --Bruno, Rob
>
>
>
>    1.
> *From:* spring [mailto:[email-masked]] *On Behalf Of *
> *Sent:* Wednesday, March 13, 2019 7:50 PM
> *To:* SPRING WG
> *Cc:* [email-masked]
> *Subject:* [spring] Working Group Adoption Call for
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Apr 2019 16:04:15 +0100

Hey Robert,

Thanks for your response, but I think you are not taking my requests at face value.

> I think you are on a very slippery slope here :) Hope you are

> double diamond skier ! 

As it happens. But perhaps that is not wholly relevant.

> information in the last octets of IPv6 address as it does not meet definition

> of the interface address. 

Am I questioning that, or am I pointing out that this is not consistent with current definitions and so it might be a good idea to get everything lined up and agreed.

> service switching vector in any network element. So even based on all

> IPv6 related RFCs you have quoted it does not violate any. 

This is certainly one way around the concern. If we define “interfaces to functions” (such as an interface to a VRF) then we may be done. That would be relatively easy to achieve with a simple section in the network programming draft.

> Then in one shot you are dismissing sound project like TeraStream

> or even recent pretty interesting proposals like draft-li-6man-service-

> aware-ipv6-network.

I am dismissing nothing. I am not even commenting on the technologies. I am seeking to get our document set to be consistent. 

> And if you look at 6man list you see that there was some discussion

> about this draft and no one questioned the point of potential "abuse"

> of semantics of IPv6 address as such.

Then (I assume) there is no issue to confirming this particular point and to getting all of the ducks lined up.

> proceed with adoption of draft-filsfils-spring-srv6-network-programming. 

Maybe you missed Bruno’s post? The draft has already been adopted by the SPRING WG. There is no question of blocking that step. 

Just to repeat (since it has apparently been repeatedly missed in reading my emails on this topic, and was even the cause of some heat in a face-to-face conversation I had in Prague) I am not seeking to block anything. What I want to do is get everything aligned. I want to be sure that we have agreement early rather than having a “fight” late in the day when pressures will be more severe.

I simply don’t understand any reluctance to bring this discussion into the open and make sure we understand how the architectures and terminology line up.

Thanks,

Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 27 Apr 2019 11:14:25 -0400

Actually Robert, a number of people have suggested on the 6man lsit that 
the overloading of IPv6 addresses to also represent functions to be 
performed is a problem.  And have put proposals on the table to get out 
of the problem rather than just pretending is a good idea.

Yours,
Joel

On 4/27/19 10:48 AM, Robert Raszuk wrote:
> Well for one let's observe that interface can be both physical and 
> logical entity and as such especially being a logical one can be tight 
> with a service switching vector in any network element. So even based on 
> all IPv6 related RFCs you have quoted it does not violate any.
> 
> Then in one shot you are dismissing sound project like TeraStream or 
> even recent pretty interesting proposals 
> like draft-li-6man-service-aware-ipv6-network. And if you look at 6man 
> list you see that there was some discussion about this draft and no one 
> questioned the point of potential "abuse" of semantics of IPv6 address 
> as such.
> 
> On Sat, Apr 27, 2019 at 11:41 AM Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi chairs,____
> 
>     __ __
> 
>     clarified before we get to a late stage and risk being forced to
>     start again.____
> 
>     __ __
> 
>     RFC 8200 defers to RFC 4291 for the definition of an IPv6 address.
>     RFC 4291 has a somewhat simplistic and possibly historic definition
>     of an IPv6 address…____
> 
>         IPv6 addresses are 128-bit identifiers for interfaces and sets
>     of____
> 
>         interfaces (where "interface" is as defined in Section 2 of
>     [IPV6]).____
> 
>     …where the reference was to RFC 2460 which (of course) is obsoleted
>     by RFC 8200. RFC 8200 has…____
> 
>         interface    a node's attachment to a link.____
> 
>         address      an IPv6-layer identifier for an interface or a set
>     of____
> 
>                      interfaces.____
> 
>     __ __
> 
>     Now, during the adoption poll, I suggested that the chairs might
>     like to ping 6man to check that the proposed work in this draft is
>     an acceptable modification to this definition.____
> 
>     __ __
> 
>     The challenge, as far as I see it, is purely semantic. That is, we
>     propose to place in the DA field of an IPv6 header a value which is
>     routable but which does not identify an interface. ____
> 
>     __ __
> 
>     I am not clear whether this represents an Update to RFC 8200 or to
>     RFC 4291, but I do strongly recommend that the chairs check with
>     6man that this approach is not going to be rejected during IETF last
>     call.____
> 
>     __ __
> 
>     Thanks,____
> 
>     Adrian____
> 
>     __ __
> 
>     __ __
> 
>     *From:*spring <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     *To:* SPRING WG <[email-masked] <mailto:[email-masked]>>;
>     <mailto:[email-masked]>
>     draft-filsfils-spring-srv6-network-programming____
> 
>     __ __
> 
>     Hi authors, WG,____
> 
>     __ __
> 
>     This document has been accepted as a new WG document.____
> 
>     __ __
> 
>     Authors, please:____
> 
>       * update email address of authors____
>       * republish current/same draft (reviewed and accepted by the WG)
>         as draft-ietf-spring-srv6-network-programming-00____
>       * publish -01 to reflect comments and agreement made on the
>         mailing list____
>       * reply to unanswered WG comments and engage resolution on open
>         points raised so far, in particular during WG adoption call.
>         E.g. (1), (2)____
> 
>     __ __
> 
>     As an additional point, this document is not intended to update RFC
>     8200. If a behavior needs to update RFC 8200, it should be defined
>     in a 6MAN draft in the 6MAN WG and normatively referenced.____
> 
>     __ __
> 
>     Thank you,____
> 
>     --Bruno, Rob____
> 
>     __ __
> 
>      1. https://mailarchive.ietf.org/arch/msg/spring/ulYVHKfb6h4fOtM8kqLmeGnVNlY____
>      2. https://mailarchive.ietf.org/arch/msg/spring/G_1ZqvInpZ9N2TX7TK8zOLa-e9I____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     *From:*spring [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     draft-filsfils-spring-srv6-network-programming____
> 
>     __ __
> 
>     Hi SPRING WG,____
> 
>     __ __
> 
>     This email initiates a three week call for working group adoption
>     for draft-filsfils-spring-srv6-network-programming. (Three weeks to
>     account for the IETF week)____
> 
>     __ __
> 
>     Please indicate your support, comments, or objection, for adopting
>     this draft as a working group item by April, 3^rd , 2019 (aka
>     2019-04-03)____
> 
>     We are particularly interested in hearing from working group members
>     that are not co-authors of this draft.____
> 
>     __ __
> 
>     We are also looking for volunteers who would be ready to perform a
>     technical review of this work at some later stage, such as before or
>     during WG the last call.____
> 
>     __ __
> 
>     document. We will need all authors and contributors to confirm their
>     IPR position on this document.____
> 
>     There is currently 1 IPR filled (2)____
> 
>     __ __
> 
>     __(1)__https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07____
> 
>     __(2)__https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming&submit=draft____
> 
>     __ __
> 
>     __ __
> 
>     Thank you,____
> 
>     --Bruno & Rob.____
> 
>     __ __
> 
>     _____________________________________________________________________________________________________________________________
> 
>     __ __
> 
>     confidentielles ou privilegiees et ne doivent donc____
> 
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous
>     avez recu ce message par erreur, veuillez le signaler____
> 
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>     messages electroniques etant susceptibles d'alteration,____
> 
>     Orange decline toute responsabilite si ce message a ete altere,
>     deforme ou falsifie. Merci.____
> 
>     __ __
> 
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;____
> 
>     they should not be distributed, used or copied without
>     authorisation.____
> 
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.____
> 
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.____
> 
>     Thank you.____
> 
>     _____________________________________________________________________________________________________________________________
> 
>     __ __
> 
>     confidentielles ou privilegiees et ne doivent donc____
> 
>     pas etre diffuses, exploites ou copies sans autorisation.. Si vous
>     avez recu ce message par erreur, veuillez le signaler____
> 
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>     messages electroniques etant susceptibles d'alteration,____
> 
>     Orange decline toute responsabilite si ce message a ete altere,
>     deforme ou falsifie. Merci.____
> 
>     __ __
> 
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;____
> 
>     they should not be distributed, used or copied without
>     authorisation.____
> 
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.____
> 
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.____
> 
>     Thank you.____
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Apr 2019 17:15:27 +0200

Hey Adrian,

> This is certainly one way around the concern. If we define “interfaces to
> functions” (such as an interface to a VRF) then we may be done. That would
> be relatively easy to achieve with a simple section in the network
> programming draft.
>

So it seems we have a solution to your concern. If WG decides to augement
the WG doc with such defintion it seems to be done deal.

Just to repeat (since it has apparently been repeatedly missed in reading
> my emails on this topic, and was even the cause of some heat in a
> face-to-face conversation I had in Prague) I am not seeking to block
> anything. What I want to do is get everything aligned. I want to be sure
> that we have agreement early rather than having a “fight” late in the day
> when pressures will be more severe.
>
>  I simply don’t understand any reluctance to bring this discussion into
> the open and make sure we understand how the architectures and terminology
> line up.
>

Well as an observer I see the interesting coincidence of such comments
popping up in the same time as alternative proposals to define yet one more
new mapping scheme of IDs to service functions and to not embed them as
part of 128 bits. So the conclusions are coming out pretty automatically
about overall strategy :)

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Apr 2019 17:23:44 +0200

Joel,

Imagine I get IPv4 /28 block or IPv6 /64 block of address space.

Isn't it my own business how I map and to what I map my non globally
routable last bits of such address ?

Does anyone care - specifically would IETF have right to care - if one /32
or /128 address is used in my house to turn on the AC or coffee machine and
some other to turn it off ?

Those would be my embedded functions in IPv4 or IPv6 addresses. Of course
there is tons of other ways to achieve such functions but those are just
examples for illustration purposes.

Cheers,
R.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Apr 2019 16:24:22 +0100

Robert, 

Coincidence is a mighty thing, but attributing coincidence to planning is the slippery slope you spoke of.

Drawing conclusions about an “overall strategy” that I might be part of is potentially offensive. Should I be offended?

Let’s just do the work and stop second guessing anything shall we? It is so much easier to do good technical work than it is to guess motivations and assign them to people.

Thanks,

Adrian

From: Robert Raszuk <[email-masked]> 
Sent: 27 April 2019 16:15
To: [email-masked]
Cc: Robert Raszuk <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

Hey Adrian,

So it seems we have a solution to your concern. If WG decides to augement the WG doc with such defintion it seems to be done deal. 

Well as an observer I see the interesting coincidence of such comments popping up in the same time as alternative proposals to define yet one more new mapping scheme of IDs to service functions and to not embed them as part of 128 bits. So the conclusions are coming out pretty automatically about overall strategy :) 

Cheers,
R.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Apr 2019 16:25:01 +0100

Robert, 

Thanks,

Adrian

Hey Adrian,

Cheers,
R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 27 Apr 2019 11:27:02 -0400

I think you have mixed two things.
You ahve the ability to abuse the standards any way you like in your own 
home (assuming you program your own devices).  The IETF is not the 
protocol police.
Operators have the ability to do whatever they want with their networks, 
and the IETF has no right or ability to stop them.  (I consider 
Terastream an example of this.)

However, when someone asks the IETF to standardize a behavior, that is a 
different game.  The IETF does have a right to question whether a given 
use in a standard is appropriate, correct, consistent, or even whether 
it is a good idea.

Yours,
Joel

On 4/27/19 11:23 AM, Robert Raszuk wrote:
> Does anyone care - specifically would IETF have right to care - if one 
> /32 or /128 address is used in my house to turn on the AC or coffee 
> machine and some other to turn it off ?
> 
> Those would be my embedded functions in IPv4 or IPv6 addresses. Of 
> course there is tons of other ways to achieve such functions but those 
> are just examples for illustration purposes.
> 
> Cheers,
> R.
> 
> 
> On Sat, Apr 27, 2019 at 5:14 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 27 Apr 2019 18:30:53 +0000

+1

Juniper Internal

> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Saturday, April 27, 2019 11:14 AM
> To: Robert Raszuk <[email-masked]>; Adrian Farrel
> <[email-masked]>
> Cc: SPRING WG <[email-masked]>; [email-masked]
> Actually Robert, a number of people have suggested on the 6man lsit that the
> overloading of IPv6 addresses to also represent functions to be performed is a
> problem.  And have put proposals on the table to get out of the problem
> rather than just pretending is a good idea.
> 
> Yours,
> Joel
> 
> > with a service switching vector in any network element. So even based
> > on all IPv6 related RFCs you have quoted it does not violate any.
> >
> > even recent pretty interesting proposals like
> > draft-li-6man-service-aware-ipv6-network. And if you look at 6man list
> >      1. https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mailarchive.ietf.org_arch_msg_spring_ulYVHKfb6h4fOtM8kqLmeGnVNl
> Y-5F-5F-5F-5F&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one0EabmcQgj6KsjT0sS3CuZ
> 8aMA8&s=XGjPJvZYgf5udr2jyaVjQ8G90gHOjxAA_z90X8xaBmM&e=
> >      2.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.
> > org_arch_msg_spring_G-5F1ZqvInpZ9N2TX7TK8zOLa-2De9I-5F-5F-5F-
> 5F&d=DwIG
> > aQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84h
> > KuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one0EabmcQgj6KsjT0sS3CuZ
> 8aMA8
> > &s=b30UpgyhpzdvGyiuzPruY8XT1qDokcqSg9R8UcqA1QE&e=
> >
> >     __ __
> >
> >     __ __
> >
> >     __ __
> >
> > __(1)__https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf
> > .org_html_draft-2Dfilsfils-2Dspring-2Dsrv6-2Dnetwork-2Dprogramming-
> 2D0
> > 7-5F-5F-5F-5F&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r
> > =Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one0Eabmc
> > Qgj6KsjT0sS3CuZ8aMA8&s=BA0uJ3F5F48VPRW9yd5-
> ePsKW03hczQxC2eAScqCSbU&e=
> >
> >
> > __(2)__https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracke
> > r.ietf.org_ipr_search_-3Fid-3Ddraft-2Dfilsfils-2Dspring-2Dsrv6-2Dnetwo
> > rk-2Dprogramming-26submit-3Ddraft-5F-5F-5F-
> 5F&d=DwIGaQ&c=HAkYuh63rsuhr
> > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwr
> >
> DThKP8&m=YUfNGQPDP3YW85one0EabmcQgj6KsjT0sS3CuZ8aMA8&s=kK8
> 4nV0AiZY7NSi
> > 5macAIqsEYRWuyKCNZBvjCXh57P8&e=
> >
> >     __ __
> >
> >     __ __
> >
> >     Thank you,____
> >
> >     --Bruno & Rob.____
> >
> >     __ __
> >
> >
> >
> ___________________________________________________________
> ___________
> > _______________________________________________________
> >
> >     __ __
> >
> ___________________________________________________________
> ___________
> > _______________________________________________________
> >
> >     __ __
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcW
> > zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one
> > 0EabmcQgj6KsjT0sS3CuZ8aMA8&s=zUKJztJlaZgGnI_23gjw-
> AzzbnLNbQKiZghQGzFng
> > xQ&e=
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcW
> > zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one
> > 0EabmcQgj6KsjT0sS3CuZ8aMA8&s=zUKJztJlaZgGnI_23gjw-
> AzzbnLNbQKiZghQGzFng
> > xQ&e=
> >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr
> 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YUfNGQPDP3YW85one0EabmcQgj6KsjT0sS3CuZ
> 8aMA8&s=zUKJztJlaZgGnI_23gjw-AzzbnLNbQKiZghQGzFngxQ&e=