Hi, SPRINGers,
This is my first post to this list.
This is about draft-ietf-spring-srv6-network-programming-06
more precisely the T.Encaps section 5.2.
Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
Alex,
The precise definition T.Encaps is done in section 5.1 [5.2 now] of
draft-ietf-spring-srv6-network-programming-06. If you have any
comment on such definition please let me know -on a separate thread
and directed to SPRING mailer-.
Thank you for the reply.
Please make the T.Encaps part of the draft easier for me to read, e.g.:
-expand what it means 'S01'; is it 'Step 01', like in BASIC programming
language?
-clarify that the original packet in transit is not modified upon
transition (modulo the Hop Limit field and the Segments Left field if
present); new packet is created to carry the original packet - yes.
-clarify what it means 'a packet (A, S2)(S3, S2, S1; SL=1)'; because it
is confusing in several ways; (A,S2) invites to think it is src and dst
addresses, but their place is switched (the normal order is Source,
Destination). S in 'S2' might mean a Source Address but also might
mean a Segment ID, or a Destination address. Confusion should be
avoided, at least in my mind.
Alex
Many thanks, Pablo.
-----Original Message----- From: ipv6 <ipv6-boun...@ietf.org> on
behalf of Alexandre Petrescu <alexandre.petre...@gmail.com> Date:
Wednesday, 11 December 2019 at 10:46 To: "i...@ietf.org"
<i...@ietf.org> Subject: Re: [spring] Question about SRv6 Insert
function
Le 11/12/2019 à 10:27, bruno.decra...@orange.com a écrit :
Brian, Pablo
Please see inline (multiple points)
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno
TGI/OLN; Fernando Gont Cc: Ron Bonica; spring@ietf.org;
6...@ietf.org; Suresh Krishnan;
draft-voyer-6man-extension-header-insertion;
draft-ietf-spring-srv6-network-programming Subject: Re: [spring]
Question about SRv6 Insert function
Bruno,
On 11-Dec-19 06:17, bruno.decra...@orange.com wrote:
Fernando,
From: Fernando Gont [mailto:ferna...@gont.com.ar] Sent:
Monday, December 9, 2019 9:54 PM
On 5/9/19 09:46, bruno.decra...@orange.com wrote: [....]
Since there have been plenty of attempts to do EH
insertion or leave the IPv6 standard ambiguous in this
respect, and the IETF has had consensus that EH insertion
is not allowed, I think it would be bad, wastefull,
tricky, and even dangerous to let a document go through
the whole publication process, and just rely on the AD
to keep the "DISCUSS" button pressed.
draft-ietf-spring-srv6-network-programming has a normative
reference to [I-D.voyer-6man-extension-header-insertion]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1
As such, from a process standpoint, it would not going to
be published before
[I-D.voyer-6man-extension-header-insertion] be itself
published as RFC. And from its name, the latter is intended
to be discussed and within control of the 6MAN WG. So I
don't think that we can say that it "just rely on the AD to
keep the "DISCUSS" button pressed."
Yes, it is just relying on that.
Situation has changed since this email: the network programming
draft has now removed text related to SRH insertion. Please
comment on the text if you see text related to SRH insertion.
For example:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
Quoting the draft for everyone to read " Every node is expected to
advertise via BGP-LS its SRv6 capabilities (e.g. how many SIDs it
can insert as part of a T.Encaps behavior)"
This is related to T.Encaps which is using IPv6 (outer)
encapsulation.
The term 'IPv6 encapsulation' has a somehow precise meaning, see
below a citation from an RFC.
Do you mean that T.Encaps 'encapsulates' just the SRv6 header or the
entire IPv6 packet that contains the SRv6 header?
RFC2473:
IPv6 encapsulation consists of prepending to the original packet
an IPv6 header and, optionally, a set of IPv6 extension headers
(see Fig.3), which are collectively called tunnel IPv6 headers.
Alex
- If you believe that T.Encaps is unclear on that, please comment
on its text. [1] - If the issue is the use of the term 'insert',
which is too close to the 'SRH insertion issue', I'm personally
fine with using a different term. E.g. "add". Please propose any
term which suits you [1]. That been said, I hope that we are not in
a situation where words are being forbidden.
[1] Preferably in the related thread, in order to help everyone
(all WG members, chairs, shepherds, ADs, IESG) to be able to track
all comments. As we'll likely be in a situations where the number
of emails may be consequent
Why would draft-voyer-6man-extension-header-insertion exists if
the SRH proponents do not intend to perform SRH insertion?
As of today, the question been asked is a WG last call on
draft-ietf-spring-srv6-network-programming. If you want to secure
that SRH insertion is not used in the document, please comment as
part of its last call.
That been said, thanks to your comment, I've seen an unused
reference for [I-D.filsfils-spring-srv6-net-pgm-insertion] that
needs to be removed
--Bruno
Brian
A question of you as a chair: does the wg you chair publish
documents based on current specs (or at the very least based
on changes that are going to happen in the near term as a
result of *existing and proven consensus*), or does spring
ship documents that implicitly betting on changes that have
no consensus?
In general, I don't see the benefit of sending a draft which we
expect would never progress to RFC. So this would not be my
preferred path. However, I guess that as always, there are
exceptions and I'm not a priori aware of a process forbidding
this. As of today, I'd rather not spend time on this
hypothetical case.
The former is how I expect WGs to operate. The later shows a
clear path to a huge pile of documents stuck at IESG review,
simply because so later in the process folks found out that
the document turns out to violate existing specs. With the
risk of an AD pressing "YES", and hence IETF has been
circumvented.
While IESG processing is beyond my paycheck (literally ;-) ), I
trust the IESG. And I don't see a reason to doubt a priori. And
even in this case, there may be a possibly to fetch back the
document from the RFC editor queue.
In short: very hypothetic case and beyond my hat. As of today,
I'd propose that we work on the text of the document.
Thank you, --Bruno
Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar ||
fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7
F1C9 3945 96EE A9EF D076 FFF1
_________________________________________________________________________________________________________________________
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_________________________________________________________________________________________________________________________
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list i...@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
