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

[Ron Bonica <[e-mail]>]

+1


Juniper Internal

> -----Original Message-----
> From: spring <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Saturday, April 27, 2019 11:14 AM
> To: Robert Raszuk <[e-mail]>; Adrian Farrel
> <[e-mail]>
> Cc: SPRING WG <[e-mail]>; [e-mail]
> Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-
> network-programming
> 
> 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://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=
> >
> >     __ __
> >
> >     __ __
> >
> >     __ __
> >
> >     *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://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.____
> >
> >     __ __
> >
> >
> >
> ___________________________________________________________
> ___________
> > _______________________________________________________
> >
> >     __ __
> >
> >     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://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=
> >
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail]
> > 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=
> >
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> 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=