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

["Joel M. Halpern" <[e-mail]>]

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:
> 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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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 <[e-mail]
>     <mailto:[e-mail]>> *On Behalf Of
>     *[e-mail] <mailto:[e-mail]>
>     *Sent:* 24 April 2019 13:13
>     *To:* SPRING WG <[e-mail] <mailto:[e-mail]>>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [spring] Working Group Adoption Call for
>     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:[e-mail]
>     <mailto:[e-mail]>] *On Behalf Of
>     *[e-mail] <mailto:[e-mail]>
>     *Sent:* Wednesday, March 13, 2019 7:50 PM
>     *To:* SPRING WG
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>
>     *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, 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.____
> 
>     __ __
> 
>     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.____
> 
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>