>SRv6+ is definitely a better proposal in terms
> 1.Adherence to IPv6 Architecture
> 2.Efficient encoding
> 3.Operational simplicity
>
> There hasn't been a single mail denying the above advantages of SRv6+
This is absolutely false!
Have you forgotten the very strong arguments against it
Authors,
Section 4 of draft-ietf-spring-srv6-network programming has the title
"Functions associated with a SID". Sections 4.1 through 4.18 enumerate
functions that can be associated with a SID, as one would expect.
Sections 4.19 and 4.20 talk about something unrelated (SR-aware applications
Authors,
What SID types can be represented by a uSID?
Also, when an SRv6 node processes a uSID, does it also need to examine the SRH
to determine of any relevant flags are set or TLVs are specified?
If it does examine the SRH and Flags.O-bit is set, is the packet punted before
or after the
Jeff,
In SRv6+ you can achieve this abstraction without a new SID type. In order to
do this, network operators:
* Associate an IPv6 address with the abstract segment
* Instantiate policy on abstract segment ingress nodes. The policy causes
the abstract segment ingress nodes to
Ole,
The IETF does not write de jure standards. At the same time, it must not
blithely progress proposals that ignore existing standards. We need to find a
balance.
Generally speaking, proposals that conform to the spirit and letter of existing
standards are better than proposals that
On 5/9/19 22:52, Darren Dukes (ddukes) wrote:
> Hey Fernando, since you’re lost, here are some more waypoints to help
> you find your way ;)
>
> - draft-ietf-spring-srv6-network-programming mentions SRH insertion in
> only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and
> all
Hi Fernando.
The takeaway I attempted to highlight is that there is in fact agreement
between 6man and spring on how to proceed, and we are proceeding as agreed to
work on the relevant documents.
Thanks!
Darren
From: Fernando Gont
Sent: Thursday, September
Fernando,
> On 5 Sep 2019, at 21:54, Fernando Gont wrote:
>
> On 5/9/19 22:30, Ole Troan wrote:
>>
>>
On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>>>
>>> We have wasted way too much time and energy with all the methafores and
>>> curious interpretations of standards by folks
inline…
> On Sep 5, 2019, at 4:01 PM, Fernando Gont wrote:
>
> On 5/9/19 22:52, Darren Dukes (ddukes) wrote:
>> Hey Fernando, since you’re lost, here are some more waypoints to help
>> you find your way ;)
>>
>> - draft-ietf-spring-srv6-network-programming mentions SRH insertion in
>> only 2
On 5/9/19 22:30, Ole Troan wrote:
>
>
>> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>>
>> We have wasted way too much time and energy with all the methafores and
>> curious interpretations of standards by folks pushing and/or supporting
>> EH insertion, really.
>
> Pot calling kettle black?
On Thu, Sep 5, 2019 at 12:20 PM Robert Raszuk wrote:
>
> Hi Tom,
>
>>
>> insertion. For instance, I'd invite you do the thought experiment
>> about what happens when an intermediate node inserts a header that
>> causes the packet to exceed the MTU of some downstream forwarding
>> node.
>
>
>
Ole,
I'm far from convinced that saying we stop - while the issue is a very big can
of worms - is a good idea. Right now, there is a clear issue on the table here
- and there are no proposals on how to address this - where addressing it would
be either to remove the issue from the draft or
Even if you remove the reference – you still have problems in 4.13 and 4.21
which manipulate the headers.
I also point out that it’s rather hard to argue that headers aren’t being
inserted when the network programming draft is explicitly mentioned as a
normative reference for
> On 5 Sep 2019, at 21:03, Fernando Gont wrote:
>
> We have wasted way too much time and energy with all the methafores and
> curious interpretations of standards by folks pushing and/or supporting
> EH insertion, really.
Pot calling kettle black?
This is an issue we all know is there. And
>
> * draft-ietf-spring-srv6-network-programming has a normative reference
> to draft-voyer-6man-extension-header-insertion
>
> * draft-voyer-6man-extension-header-insertion is about EH insertion
>
> * EH insertion is forbidden by RFC8200
>
> We have wasted way too much time and energy with all
Hi Tom,
> insertion. For instance, I'd invite you do the thought experiment
> about what happens when an intermediate node inserts a header that
> causes the packet to exceed the MTU of some downstream forwarding
> node.
Absolutely.
But SRH is meaningful only within a given domain.
At least
On 5/9/19 21:00, Robert Raszuk wrote:
> * According to RFC 8200, segment endpoints can insert, change, or
> delete extension headers. However, transit nodes that are not
> segment nodes cannot insert, change or delete extension headers
Seriously?
The text in RFC8200 is there with
On 5/9/19 18:42, Alexander Vainshtein wrote:
> Fernando,
>
> With regard to the last statement in your email "If you create a new
> packet, and you put your own address in the SA of the packet, and
> encapsulate what you received in the IPv6 payload, you're free to
> generate as many EHs as you
On 5/9/19 18:31, Robert Raszuk wrote:
> Fernando,
>
> I am taking you extremely seriously ! In fact some of your emails make
> me even worried.
>
> You say in one email that encapsulation is allowed and that the event of
> encapsulation is the same as sourcing.
>
> So please notice text in
On Thu, Sep 5, 2019 at 11:01 AM Robert Raszuk wrote:
>
> Hi Ron,
>
> Nope that is not correct interpretation. Let me try to rephrase it ...
>
> An IPv6 path contains a source node, a destination node, and transit nodes
> Transit nodes belong to network operators which move the packets
> When
Ron,
another, and quite important use of BSID in SR-MPLS is to provide an anchor
point to another domain/layer and an abstraction to program this layer without
understanding its semantics.
SR/RSVP-TE or IP/Opto would be a perfect example of that,
draft-anand-spring-poi-sr describes such case.
Hi Ron,
Nope that is not correct interpretation. Let me try to rephrase it ...
- An IPv6 path contains a source node, a destination node, and transit
nodes
- Transit nodes belong to network operators which move the packets
- When packet enters operator's network it can be
Robert,
I think that I can summarize what you are saying as follows:
* An IPv6 path contains a source node, a destination node, and transit nodes
* Some transit nodes are also segment endpoints. Segment endpoints are
identified by either of the following:
* The initial value of
Hi Alexander,
SRv6+ does not currently define a binding SID. If one were ever needed, it
would be easy enough to specify and implement. When a segment endpoint
encountered a binding SID, it would:
* Decrement Segments Left
* Copy an IPv6 address from the SFIB to the IPv6 destination
Fernando,
> Ron,
>
> On 5/9/19 06:01, Ron Bonica wrote:
> > Fernando, Zhenqiang,
> >
> > You both have valid points. Maybe I am becoming too tolerant of
> > deviations from the specification.
>
> This is not a deviation in the spec. It's an outright violation of the spec.
>
> This topic has a
Ron,
On 5/9/19 06:01, Ron Bonica wrote:
> Fernando, Zhenqiang,
>
> You both have valid points. Maybe I am becoming too tolerant of
> deviations from the specification.
This is not a deviation in the spec. It's an outright violation of the spec.
This topic has a rich history in 6man, which I
On Thu, 5 Sep 2019 at 13:02, Ron Bonica
wrote:
>
> Fernando, Zhenqiang,
>
>
>
> You both have valid points. Maybe I am becoming too tolerant of deviations
> from the specification.
>
>
I think by definition RFCs are the authoritative definition of how
protocols and their implementations are to
> From: Fernando Gont [mailto:fg...@si6networks.com]
> Sent: Thursday, September 5, 2019 4:56 PM
>
> On 5/9/19 17:46, bruno.decra...@orange.com wrote:
> > Fernando,
> >
> >
> >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
> >> Sent: Tuesday, September 3, 2019 1:18
Fernando,
With regard to the last statement in your email "If you create a new packet,
and you put your own address in the SA of the packet, and encapsulate what you
received in the IPv6 payload, you're free to generate as many EHs as you wish",
do you see the need to comply with the 8200
On 5/9/19 17:46, Robert Raszuk wrote:
> Quote from RFC8200:
>
>Extension headers (except for the Hop-by-Hop Options header) are not
>processed, inserted, or deleted by any node along a packet's delivery
>path, *until the packet reaches the node* (or each of the set of nodes,
>in
On 5/9/19 17:46, bruno.decra...@orange.com wrote:
> Fernando,
>
>
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
>> Sent: Tuesday, September 3, 2019 1:18 PM
>>
>> Hello, Suresh,
>>
>> On 2/9/19 19:07, Suresh Krishnan wrote:
>> []
> So, we should probably
Quote from RFC8200:
Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, *until the packet reaches the node* (or each of the set of nodes,
in the case of multicast) identified in the
Fernando,
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
> Sent: Tuesday, September 3, 2019 1:18 PM
>
> Hello, Suresh,
>
> On 2/9/19 19:07, Suresh Krishnan wrote:
> []
> >>> So, we should probably explore the motivation for Option 2). If the
> >>> motivation is
>As far as I know, but I'm trying to stay away from the actual proposals and ar
>gue this generally, no-one is proposing to update the RFC8200 header insertion
> text.
>What people are proposing are for specific domains. And given that, I believe
>people need to argue the technical merits of
On 5/9/19 17:28, Robert Raszuk wrote:
[]
>
> Now if 6man response to proposl of SRv6 use case for FRR with TI-LFA
> will state "IPv6 was not designed for that" - I am fine.
As I have reiterated numerous times, nobody is arguing that.
My argument is: you can't simply violate specs at will.
On 5/9/19 17:28, Robert Raszuk wrote:
>
>
> 3) Now there's at least one I-D in spring that ignores RFC8200, and
> proposes EH-insertion as if it was allowed, essentially circumventing
> RFC8200, and IETF consensus.
>
>
> Incorrect. RFC8200 makes it black on white clear that
> 3) Now there's at least one I-D in spring that ignores RFC8200, and
> proposes EH-insertion as if it was allowed, essentially circumventing
> RFC8200, and IETF consensus.
Incorrect. RFC8200 makes it black on white clear that insertion, deletion
and mangling is allowed in IPv6 if destination is
Joel M. Halpern wrote on 05/09/2019 14:11:
Part of the reason we write restrictions and requirements into RFCs is
so that we do not have to repeat the arguments.
If the proponents of the insertion have arguments for why it is now
okay, they need to make those arguments. And they need to make
Hi Ole,
On Thu, Sep 05, 2019 at 03:05:14PM +0200, Ole Troan wrote:
> Fernando,
>
> >> The IETF is not writing de jure standards.
> >> In fact reality is quite different, and the Internet evolves the way it
> >> does somewhat independently of what documents the IETF produces.
one may then
On Thu, Sep 5, 2019 at 6:35 AM Ole Troan wrote:
>
> Joel,
>
> > Part of the reason we write restrictions and requirements into RFCs is so
> > that we do not have to repeat the arguments.
> >
> > If the proponents of the insertion have arguments for why it is now okay,
> > they need to make
On 5/9/19 16:46, Tim Chown wrote:
>> On 5 Sep 2019, at 14:05, Ole Troan wrote:
>>
>> I have not changed my position with regards to header insertion.
>> I'm arguing that you should argue technical merit on actual proposals.
>> Instead of trying to make RFC documents apply as laws and slap people
On 5/9/19 16:34, Ole Troan wrote:
> Joel,
>
>> Part of the reason we write restrictions and requirements into RFCs is so
>> that we do not have to repeat the arguments.
>>
>> If the proponents of the insertion have arguments for why it is now okay,
>> they need to make those arguments. And
Hi Reji,
> SRv6+ confirms to the V6 architecture, explains the rationale behind the
> design and is non ambiguous to start with. Till now there has not been any
> valid shortcomings brought forth with the Srv6+ design. I saw a mention that
> SRv6+ needs to distribute the SID to address
Joel,
> Part of the reason we write restrictions and requirements into RFCs is so
> that we do not have to repeat the arguments.
>
> If the proponents of the insertion have arguments for why it is now okay,
> they need to make those arguments. And they need to make sure that the
> discussion
On 5/9/19 16:05, Ole Troan wrote:
> Fernando,
>
>>> The IETF is not writing de jure standards.
>>> In fact reality is quite different, and the Internet evolves the way it
>>> does somewhat independently of what documents the IETF produces.
>>> In fact I know of no networking products (or
Part of the reason we write restrictions and requirements into RFCs is
so that we do not have to repeat the arguments.
If the proponents of the insertion have arguments for why it is now
okay, they need to make those arguments. And they need to make sure
that the discussion is taken to the
Fernando,
>> The IETF is not writing de jure standards.
>> In fact reality is quite different, and the Internet evolves the way it does
>> somewhat independently of what documents the IETF produces.
>> In fact I know of no networking products (or deployments) that follow the
>> intent and
On 5/9/19 11:18, Ole Troan wrote:
[...]
>
> Let me quote Tony Li's response to Fernando's escalation email to the
> architecture list:
>
> "The fact of the matter is that the IETF is completely helpless to prevent
> such things.
> True, it can block standardization, but if the market wants
On 5/9/19 11:23, Ole Troan wrote:
> Fernando,
>
> See my email to Ron.
>
> Just a short point with regards to your claim:
> "If you want to do it, the first step is to update RFC8200".
>
> Let's be clear that this is your own personal view and nothing more than that.
I have a few questions for
On 5/9/19 11:18, Ole Troan wrote:
> Dear Ron,
>
> The IETF is not writing de jure standards.
> In fact reality is quite different, and the Internet evolves the way it does
> somewhat independently of what documents the IETF produces.
> In fact I know of no networking products (or deployments)
Hi,
Ok but this extra insertion is just one of possible SR applications and has
no bearing on SRv6 architecture and all other SRv6 documents running via
various stages of IETF process like number of folks are voicing on the list
just to mud the waters.
There is valid problem statement presented
*Dear Alexander, *
On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:
> Robert,
>
> I fully agree with you that RFC 8200 does not prevent a node that owns the
> destination address of the IPv6 header to insert EH.
>
Great - Are we done with this "EH
Robert,
I fully agree with you that RFC 8200 does not prevent a node that owns the
destination address of the IPv6 header to insert EH.
However, RFCV 8200 recommends (?) not to have more than one EH header of any
type (excluding the Destination Options header that can occur no more than
twice –
Hi Fernando,
> If folks want to do EH insertion, the #1 step is to publish a document
> that updates RFC8200 such that the "EHs must not be inserted..." is
> replaced with something else or eliminated.
I have very basic question to close this debate.
Is IP encapsulation of the packet allowed
Fernando,
See my email to Ron.
Just a short point with regards to your claim:
"If you want to do it, the first step is to update RFC8200".
Let's be clear that this is your own personal view and nothing more than that.
Best regards,
Ole
> On 5 Sep 2019, at 02:34, Fernando Gont wrote:
>
>
Dear Ron,
The IETF is not writing de jure standards.
In fact reality is quite different, and the Internet evolves the way it does
somewhat independently of what documents the IETF produces.
In fact I know of no networking products (or deployments) that follow the
intent and spirit of RFC8200. I
56 matches
Mail list logo
