Subject: Re: [spring] Question about SRv6 Insert function

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Dec 2019 15:54:26 -0500

On 5/9/19 09:46, [email-masked] 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.

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?

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.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 17:17:03 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Monday, December 9, 2019 9:54 PM
> 

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.

> 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.
 
> 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,

_________________________________________________________________________________________________________________________

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2019 08:36:27 +1300

Bruno,

> 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

Why would draft-voyer-6man-extension-header-insertion exists if the SRH proponents do not intend to perform SRH insertion?

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 20:44:59 +0100

Brian,

> Situation has changed since this email: the network programming draft has
> now removed text related to SRH insertion.
> Why would draft-voyer-6man-extension-header-insertion exists if the SRH
> proponents do not intend to perform SRH insertion?
>

What Bruno is describing is the new situation after removal of SRH
insertion at non SR midpoints from NP draft under last call.

Section 8.2 is referring to SRH insertion at the SR encapsulation node (for
example ingress to the domain).

draft-voyer-6man-extension-header-insertion  is progressing as recommended
to relax the RFC8200 restricting EH insertion at any arbitrary node - not
necessarily segment endpoint.

Regards,
R.

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Dec 2019 12:10:15 -0800

My apologies for raising something that might have already been discussed a
rejected, but I'm finding it non-trivial to track this wide-ranging
discussion across multiple mailing lists.

Regardless of how SRv6 works now (using header insertion, as Darren said in
Singapore), I'm wondering if it would suffice to say that the ingress
encapsulation node could/should pad the SRH with an operationally
determined amount of extra space to allow for header re-writing.

This would effectively turn the SRH into a scratch space could be specified
as able to be re-written by SR-aware nodes along the path.

For example, if the ingress router new the SR domain's carefully curated
path MTU, it could pad out the SRH to some fraction of that, a la:

    {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_2, sr_rtr_1, ::0,
::0, ::0]}

then permit intermediate SR routers to rewrite all of that scratch space
for router insertion/deletion as needed.  For example, if sr_rtr_1 needs to
route around sr_rtr_2 via sr_rtr_4 and sr_rtr_5 it could rewrite this as:

    {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_5, sr_rtr_4,
sr_rtr_1, ::0, ::0]}

If there's no scratch space left with which to fiddle then generate an ICMP
error to the ingress router (ICMP source address selection aside).  The
rules for examining this header scratch space in the returned ICMP error
might need to be suitably lax.

I'm unsure of how this would interact with the HMAC bits, but overall, if
this could work then perhaps we don't need to worry about insertion anymore.

Yes, there's more overhead on each packet, but that should be tunable by
the operator based on things like (1) operational path mtu in the SR
domain, (2) operationally acceptable padding overhead, (3) expected space
required for adding routers for re-routing or whatever...

On Tue, Dec 10, 2019 at 11:45 AM Robert Raszuk <[email-masked]> wrote:

> Brian,
>
> > Situation has changed since this email: the network programming draft
>> has now removed text related to SRH insertion.
> insertion at non SR midpoints from NP draft under last call..
>
> Section 8.2 is referring to SRH insertion at the SR encapsulation node
> (for example ingress to the domain).
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 21:18:42 +0100

Hi Erik,

What you are proposing IMHO is not needed.

Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so
is already doing an insertion of new SRH while maintaining src address and
previous  SRH content (modulo updating it). That is legally permitted
operation based on IPv6 tunneling RFC.

The word insertion has been questioned in the context of adding SRH at non
SR midpoints (say for TI-LFA) into existing "private" IPv6 header. For this
sure one could think of more structure (bypass section) of original SRH
already present or addition of 2nd SRH.

Thx
R.

On Tue, Dec 10, 2019 at 9:10 PM Erik Kline <[email-masked]> wrote:

> My apologies for raising something that might have already been discussed
> a rejected, but I'm finding it non-trivial to track this wide-ranging
> Regardless of how SRv6 works now (using header insertion, as Darren said
> in Singapore), I'm wondering if it would suffice to say that the ingress
> This would effectively turn the SRH into a scratch space could be
> specified as able to be re-written by SR-aware nodes along the path.
>
> If there's no scratch space left with which to fiddle then generate an
> ICMP error to the ingress router (ICMP source address selection aside).
> The rules for examining this header scratch space in the returned ICMP
> error might need to be suitably lax.
>
>> insertion at non SR midpoints from NP draft under last call...
>>
>> draft-voyer-6man-extension-header-insertion  is progressing as
>> recommended to relax the RFC8200 restricting EH insertion at any arbitrary
>> node - not necessarily segment endpoint.
>>
>> Regards,
>> R.
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Dec 2019 12:34:00 -0800

> already present or addition of 2nd SRH.

If there were no resolution to the insertion question vis a vis RFC 8200,
then would it then suffice to recommend that ingress nodes should include
some padding for these non-SR midpoints to play with (iff. the network has
such midpoints), and otherwise abide by RFC 8200?

Thx

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 21:42:21 +0100

The issue is that RFC8200 forbids even modification to any EH unless the
node is a destination node in top most IPv6 header.

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Dec 2019 12:54:20 -0800

Ah right.

Still, in terms of the things that could be relaxed in 8200, allowing the
SRH to be treated more like a Hop-by-Hop header might be more palatable
than things that change the effective MTU.

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Dec 2019 08:02:21 +1100

Perhaps we need to update RFC8200 and eliminate the source address field,
or at least update it so that it can hold a multicast address, indicating
the packet has multiple source devices.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 22:08:16 +0100

Well I take it as a joke ... as I am sure you are aware that SRH already
contains those verbatim.

PS.

Note that SRm6 would require a local mapping database to decipher those in
CRH.

On Tue, Dec 10, 2019 at 10:02 PM Mark Smith <[email-masked]> wrote:

>>> If there were no resolution to the insertion question vis a vis RFC
>>>> 8200, then would it then suffice to recommend that ingress nodes should
>>>> include some padding for these non-SR midpoints to play with (iff. the
>>>> network has such midpoints), and otherwise abide by RFC 8200?
>>>>

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Dec 2019 08:18:35 +1100

On Wed, 11 Dec 2019, 08:08 Robert Raszuk, <[email-masked]> wrote:

>
> Well I take it as a joke ...
>

It's as serious as performing major updates on a packet and not updating
its source address.

as I am sure you are aware that SRH already contains those verbatim.
>>> Still, in terms of the things that could be relaxed in 8200, allowing
>>> the SRH to be treated more like a Hop-by-Hop header might be more palatable
>>>> The issue is that RFC8200 forbids even modification to any EH unless
>>>> the node is a destination node in top most IPv6 header.
>>>>
>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 22:23:42 +0100

>  and not updating its source address.

Honestly speaking to me personally this is not a strict requirement to
accomplish the necessary functionality discussed.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Dec 2019 13:45:48 -0800

Robert,

> On Dec 10, 2019, at 12:42 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> The issue is that RFC8200 forbids even modification to any EH unless the node is a destination node in top most IPv6 header.

I don’t think that is true.   The options in the Hop-by-Hop Options header and the Destination Options Header allow the definition of options that support modifications.   See Section 4.2, specifically:

   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en route to the
   packet's final destination.  When an Authentication header is present
   in the packet, for any option whose data may change en route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

       0 - Option Data does not change en route
       1 - Option Data may change en route

Other EH’s allow for different forms of modification, for example SRH allows for TLV modification, see Section 2.1.

Bob

> 
> 
> If there were no resolution to the insertion question vis a vis RFC 8200, then would it then suffice to recommend that ingress nodes should include some padding for these non-SR midpoints to play with (iff. the network has such midpoints), and otherwise abide by RFC 8200?

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Dec 2019 23:05:44 +0100

> Other EH’s allow for different forms of modification, for example SRH
allows for TLV modification, see Section 2.1.

Section 2.1 talks about segment endpoint and that is where IPv6 outer
header destination address matches the node address doing the modification.
If you stating that it can be modified by any via node - that's pretty
cool.

Regarding Hop-by-Hop - of course.

For Destination Options to allow to define fields which can be modified by
non outer IPv6 destination network elements - good to know.

Thx,
R.

On Tue, Dec 10, 2019 at 10:45 PM Bob Hinden <[email-masked]> wrote:

> I don’t think that is true.   The options in the Hop-by-Hop Options header
> and the Destination Options Header allow the definition of options that
> support modifications.   See Section 4.2, specifically:
>
> Other EH’s allow for different forms of modification, for example SRH
> allows for TLV modification, see Section 2.1.
>
> Bob
>
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Dec 2019 16:56:48 -0800

Robert,

> On Dec 10, 2019, at 2:05 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Section 2.1 talks about segment endpoint and that is where IPv6 outer header destination address matches the node address doing the modification.

I think it is clear that the intent is that destination options are only modified by the destination, that’s how destination options, routing header, etc., etc. work.   The Hop-by-Hop option extension header can be modified by any node as defined by a specific option.

> If you stating that it can be modified by any via node - that's pretty cool.
> 

The same option format is used for destination and hop-by-hop option extension headers.  The option text definition about changing en route doesn’t make any distinction between destination and hop-by-hop options.  Personally, I don’t have a big problem if an intermediate node decides to parse extension headers and modified one based on the definition of the specific EH.

I am not sure why that is very useful, but I don’t think it would break anything.   Unlike inserting or deleting.

Bob

> For Destination Options to allow to define fields which can be modified by non outer IPv6 destination network elements - good to know.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2019 14:10:49 +1300

Robert,

On 11-Dec-19 09:18, Robert Raszuk wrote:
> Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so is already doing an insertion of new SRH 

That isn't "insertion" in the sense of draft-voyer. It's prepending an extra layer of encapsulation, which is indeed just fine and I don't think anyone here is objecting to it. The spring draft currently uses (IMHO) imprecise language, even in its pseudo-code, but if all it's doing is describing successive layers of encapsulation that's fine too. Wasted bytes perhaps, but that isn't an IETF problem.

Whether prepending new headers, each with their own SRH, is the best way of doing service-based traffic engineering is another question. Having just reviewed draft-ietf-bess-nsh-bgp-control-plane for Gen-ART, I do believe there's more than one possible approach.

Regards
   Brian

> while maintaining src address and previous  SRH content (modulo updating it). That is legally permitted operation based on IPv6 tunneling RFC. 
> 
> The word insertion has been questioned in the context of adding SRH at non SR midpoints (say for TI-LFA) into existing "private" IPv6 header. For this sure one could think of more structure (bypass section) of original SRH already present or addition of 2nd SRH. 
> 
> Thx
> R.
> 
> 
> 
> 
> 
> 
> On Tue, Dec 10, 2019 at 9:10 PM Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     My apologies for raising something that might have already been discussed a rejected, but I'm finding it non-trivial to track this wide-ranging discussion across multiple mailing lists.
> 
>     Regardless of how SRv6 works now (using header insertion, as Darren said in Singapore), I'm wondering if it would suffice to say that the ingress encapsulation node could/should pad the SRH with an operationally determined amount of extra space to allow for header re-writing.
> 
>     This would effectively turn the SRH into a scratch space could be specified as able to be re-written by SR-aware nodes along the path.
> 
>     For example, if the ingress router new the SR domain's carefully curated path MTU, it could pad out the SRH to some fraction of that, a la:
> 
>         {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_2, sr_rtr_1, ::0, ::0, ::0]}
> 
>     then permit intermediate SR routers to rewrite all of that scratch space for router insertion/deletion as needed.  For example, if sr_rtr_1 needs to route around sr_rtr_2 via sr_rtr_4 and sr_rtr_5 it could rewrite this as:
> 
>         {segments_left=2, last_entry=5, [sr_rtr_3, sr_rtr_5, sr_rtr_4, sr_rtr_1, ::0, ::0]}
> 
>     If there's no scratch space left with which to fiddle then generate an ICMP error to the ingress router (ICMP source address selection aside).  The rules for examining this header scratch space in the returned ICMP error might need to be suitably lax.
> 
>     I'm unsure of how this would interact with the HMAC bits, but overall, if this could work then perhaps we don't need to worry about insertion anymore.
> 
>     Yes, there's more overhead on each packet, but that should be tunable by the operator based on things like (1) operational path mtu in the SR domain, (2) operationally acceptable padding overhead, (3) expected space required for adding routers for re-routing or whatever...
> 
>     On Tue, Dec 10, 2019 at 11:45 AM Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Brian,
> 
>         What Bruno is describing is the new situation after removal of SRH insertion at non SR midpoints from NP draft under last call... 
> 
>         Section 8.2 is referring to SRH insertion at the SR encapsulation node (for example ingress to the domain). 
> 
>         draft-voyer-6man-extension-header-insertion  is progressing as recommended to relax the RFC8200 restricting EH insertion at any arbitrary node - not necessarily segment endpoint. 
> 
>         Regards,
>         R.
> 
> 
> 
> 
> 
> 
>          
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 11 Dec 2019 02:02:57 +0000

Thanks Bob for sharing your opinion.
I fully agree with that, and I either don’t have any problem if an intermediate node decides to parse extension headers and modified one based on the definition of the specific EH.

Regards,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, December 11, 2019 8:57 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>
Subject: Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert,

Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 08:25:10 +0100

Le 10/12/2019 à 22:02, Mark Smith a écrit :
> Perhaps we need to update RFC8200 and eliminate the source address 
> field, or at least update it so that it can hold a multicast address, 
> indicating the packet has multiple source devices.

I think this is a joke :-)

I would like to remark though that the concept of using src multicast 
addresses might have some application which might not be able to be 
dealt with otherwise.

Alex

> 
> On Wed, 11 Dec 2019, 07:54 Erik Kline, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Ah right.
> 
>     Still, in terms of the things that could be relaxed in 8200,
>     allowing the SRH to be treated more like a Hop-by-Hop header might
>     be more palatable than things that change the effective MTU.
> 
>     On Tue, Dec 10, 2019 at 12:42 PM Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> 
>         The issue is that RFC8200 forbids even modification to any EH
>         unless the node is a destination node in top most IPv6 header.
> 
> 
>             If there were no resolution to the insertion question vis a
>             vis RFC 8200, then would it then suffice to recommend that
>             ingress nodes should include some padding for these non-SR
>             midpoints to play with (iff. the network has such
>             midpoints), and otherwise abide by RFC 8200?
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 09:37:10 +0100

Hi Brian,

> is already doing an insertion of new SRH
>
> That isn't "insertion" in the sense of draft-voyer.

Correct. But we are not discussing draft-voyer here.

I think recent mail threads prove that it is much better to discuss one
topic at a time rather then mix three different and pretty orthogonal
"issues" interchangeably.

>  . It's prepending an extra layer of encapsulation, which is indeed just
> fine and I don't think anyone here is objecting to it. The spring draft
> currently uses (IMHO) imprecise language, even in its pseudo-code, but if
> all it's doing is describing successive layers of encapsulation that's fine
> too. Wasted bytes perhaps, but that isn't an IETF problem.

Great that we agree.

> Whether prepending new headers, each with their own SRH, is the best way
> of doing service-based traffic engineering is another question. Having just
> reviewed draft-ietf-bess-nsh-bgp-control-plane for Gen-ART, I do believe
> there's more than one possible approach.
>

100% agreed. In fact as you may have seen I have another non data plane,
but control plane proposal posted:
https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00

Kind regards,
R.

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 09:27:33 +0000

Brian, Pablo

Please see inline (multiple points)

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, December 10, 2019 8:36 PM
> To: DECRAENE Bruno TGI/OLN; Fernando Gont
> Cc: Ron Bonica; [email-masked]; [email-masked]; Suresh Krishnan; draft-voyer-6man-extension-header-insertion; draft-ietf-spring-srv6-network-programming
> Subject: Re: [spring] Question about SRv6 Insert function
> 
> Bruno,
> 

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.
- 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 10:46:25 +0100

> 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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:04:11 +0000

Brian,

Draft-ietf-spring-srv6-network-programming does NOT have any text that proposes SRH insertion.
The text you are pointing in Section 8.2 uses the word "Insert" in a different context that has nothing to do with SRH insertion. I have replaced the word insert throughout the entire draft to avoid this kind of confusions (rev06).

Thank you,
Pablo. 

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Tuesday, 10 December 2019 at 20:37
To: "[email-masked]" <[email-masked]>, Fernando Gont <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Suresh Krishnan <[email-masked]>, draft-voyer-6man-extension-header-insertion <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function

    For example:

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:05:36 +0000

Alex,

The precise definition T.Encaps is done in section 5.1 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-.

Many thanks,
Pablo.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Date: Wednesday, 11 December 2019 at 10:46
To: "[email-masked]" <[email-masked]>
Subject: Re: [spring] Question about SRv6 Insert function

    

    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Dec 2019 08:18:35 +0100

Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
> Alex,
> 
> The precise definition T.Encaps is done in section 5.1 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.

I might subscribe and post to SPRING later.

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 packet in transit
  is not modified upon (modulo the Hop Limit field); 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.

I might subscribe to SPRING and read the draft and comment.

Alex

> 
> Many thanks, Pablo.
> 
> -----Original Message----- From: ipv6 <[email-masked]> on
> behalf of Alexandre Petrescu <[email-masked]> Date:
> Wednesday, 11 December 2019 at 10:46 To: "[email-masked]"
> <[email-masked]> Subject: Re: [spring] Question about SRv6 Insert
> function
> 
> 
> 
>>> Sent: Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno
>>> TGI/OLN; Fernando Gont Cc: Ron Bonica; [email-masked];
>>> [email-masked]; Suresh Krishnan;
>>> draft-voyer-6man-extension-header-insertion;
>>> draft-ietf-spring-srv6-network-programming Subject: Re: [spring]
>>> Question about SRv6 Insert function
>>> 
>>> Bruno,
>>> 
>>>>> From: Fernando Gont [mailto:[email-masked]] Sent:
>>>>> Monday, December 9, 2019 9:54 PM
>>>>> 
>>>>> On 5/9/19 09:46, [email-masked] 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] 
>>>>>> 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."
>>>>> 
>>>> 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: 
>> 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)"
>> 
>> 
> The term 'IPv6 encapsulation' has a somehow precise meaning, see
> below a citation from an RFC.
> 
>> 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: [email-masked] ||
>>>>> [email-masked] 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.
>>>> 
>>>> [email-masked] 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.
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Dec 2019 13:54:39 -0500

On Wed, Dec 11, 2019 at 3:37 AM Robert Raszuk <[email-masked]> wrote:

> Hi Brian,
>
> > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap
>> so is already doing an insertion of new SRH
>>

  Robert

    Your ip-te teas WG draft sounds like a fine solution and maybe can be
used in conjunction with Gen-ART sfc draft in centralized SDN controller
based architecture.  So with draft is pulls the control plane function or
Ti-LFA and SR-TE and/or binding SID policies into control plane nodes which
could be the PEs eliminating SRH state in the P core.  So this in essence
using this feature we would save on overhead bytes with the additional 6in6
encap plus SRH state.

Warm regards,

Gyan

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Dec 2019 20:21:54 +0100

Thank you.

Yes this draft can work with controller, but can also work without one.

Please observe that I am (re)using BGP extension to propagate control plane
information which can originate from any network element not necessarily a
central controller. Nevertheless using it with conjunction of some oracle
to optimize global network TE or steer some packets towards selected SFCs
is by all means a sound approach.

Kind regards,
Robert

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Dec 2019 15:31:33 +0100

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Dec 2019 15:34:49 +0100

sorry, worng manipluation

Le 16/12/2019 à 15:31, Alexandre Petrescu a écrit :
>>>> From: Brian E Carpenter [mailto:[email-masked]] Sent: 
>>>> Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno
>>>>> notify the sender and delete this message and its attachments. As 
>>>>> emails may be altered, Orange is not liable for messages