Hi Ron, the authors are suggesting this document for working group adoption,
not for last call.
When the working group adopts it, the working group starts to work on it.
If the working group decides to address header insertion and address that with
6man then the working group can take on that work, but it does not need to
block this document being adopted.
Darren
From: spring <spring-boun...@ietf.org> on behalf of Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org>
Date: Sunday, March 17, 2019 at 4:53 PM
To: "bruno.decra...@orange.com" <bruno.decra...@orange.com>, SPRING WG
<spring@ietf.org>
Cc: "draft-filsfils-spring-srv6-network-programm...@ietf.org"
<draft-filsfils-spring-srv6-network-programm...@ietf.org>
Subject: Re: [spring] IPR Poll for
draft-filsfils-spring-srv6-network-programming
Bruno,
While I like many things about this draft, I don’t think that it is ready for
adoption. Reasons follow:
* Section 4.1 appears to contradict Section 4.3.1 of
draft-ietf-6man-segment-routing-header. In particular, consider the behavior
when Segments Left equals 0.
* Sections 4.13, 4.14. 4.21.1 and 4.21.2 appear to be in conflict with RFC
8200 [1] [2].
* The intent of section 4.19 is unclear.
* As Adrian points out, the draft extends the semantics of the IPv6
address. Such a decision may have wide-reaching impact, and should be
socialized with a wider community (6man, INTAREA WG, V6OPS)
* The draft appears to be in conflict with
draft-ietf-6man-segment-routing-header regarding how extension headers after
the SRH are processed. According to draft-ietf-6man-segment-routing-header,
subsequent extension headers are processed out of order, potentially in
conflict with RFC 8200. According to this draft, subsequent extension headers
are ignored.
[1] According to RFC 8200, “Each extension header should occur at most once,
except for the Destination Options header, which should occur at most twice
(once before a Routing header and once before the upper-layer header).”
[2] According to RFC 8200, “extension headers must be processed strictly in the
order they appear in the packet” . Sections 4.13 and 4.14 violate this rule by
prepending an SRH before the SRH that is currently being processed.
Ron
From: spring <spring-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, March 13, 2019 2:50 PM
To: SPRING WG <spring@ietf.org>
Cc: draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming
Hi authors, SPRING WG,
In parallel to the call for adoption for
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for
IPR.
If you are aware of IPR that applies to
draft-filsfils-spring-srv6-network-programming please respond to this email.
If you are aware of IPR, please indicate whether it has been disclosed in
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more
details).
If you are an *author or contributor* please respond to this email regardless
of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if you
are aware of IPR that has not yet been disclosed.
This document will not advance into the working group until IPR confirmations
have been received from all authors and contributors.
Thank you,
(1)
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dsrv6-2Dnetwork-2Dprogramming-2D07&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=g5euhKG6OY3m1hMFewvX_AhsPNPcaeHrTSLS3oY3KoM&s=5KlDTs7QncIP0FnevaMhAHEIjoQLlCw9xVVUrR40dqY&e=>
--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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
