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

[Robert Raszuk <[e-mail]>]

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