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