Subject: [spring] Fwd: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 21 Sep 2019 04:34:30 +0000

Hello everyone, we’ve just submitted an updated draft that explains why SRH insertion is performed in an SR domain, how it is accomplished and why it is safe within the SR domain.

The authors look forward to your comments and suggestions on how to improve this document.

Thanks!
  Darren (on behalf of the authors)

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt
Date: September 21, 2019 at 12:20:13 AM EDT

A new version of I-D, draft-voyer-6man-extension-header-insertion-07.txt
has been successfully submitted by Darren Dukes and posted to the
IETF repository.

Name: draft-voyer-6man-extension-header-insertion
Revision: 07
Title: Insertion of IPv6 Segment Routing Headers in a Controlled Domain
Document date: 2019-09-20
Group: Individual Submission
Pages: 13
URL:            https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt
Status:         https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
Htmlized:       https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion
Diff:           https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07

Abstract:
  Traffic traversing an SR domain is encapsulated in an outer IPv6
  header for its journey through the SR domain.

  To implement transport services strictly within the SR domain, the SR
  domain may require insertion or removal of an SRH after the outer
  IPv6 header of the SR domain.  Any segment within the SRH is strictly
  contained within the SR domain.

  The SR domain always preserves the end-to-end integrity of traffic
  traversing it.  No extension header is manipulated, inserted or
  removed from an inner transported packet.  The packet leaving the SR
  domain is exactly the same (except for the hop-limit update) as the
  packet entering the SR domain.

  The SR domain is designed with link MTU sufficiently greater than the
  MTU at the ingress edge of the SR domain.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 Sep 2019 00:54:32 -0400

I see where the draft defines a set of constraints.
The constraint that there be no other extension headers is a fairly 
drastic constraint, which would seem a cause for concern.

Putting that aside however, the draft does not seem to provide any 
explanation for why insertion rather than additional encapsulation is 
used.  Particularly given the assumption that the MTU is large enough, 
it seems the encapsulation could be used for all insertion cases.

Yours,
Joel

On 9/21/2019 12:34 AM, Darren Dukes (ddukes) wrote:
> Hello everyone, we’ve just submitted an updated draft that explains why 
> SRH insertion is performed in an SR domain, how it is accomplished and 
> why it is safe within the SR domain.
> 
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *Subject: **New Version Notification for 
>> draft-voyer-6man-extension-header-insertion-07.txt*
>> *Date: *September 21, 2019 at 12:20:13 AM EDT
>>
>>
>> Name:draft-voyer-6man-extension-header-insertion
>> Revision:07
>> Title:Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>> Document date:2019-09-20
>> Group:Individual Submission
>> Pages:13
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
>>
>> Abstract:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: SING Team <[email-masked]>
Date: Sat, 21 Sep 2019 19:48:57 +0800

Hi Joel and Dukes, Glad to see the safety situation is more clear now, although Action2 inevitably violates RFC8200 design principle yet. I can feel you have made many efforts to clarify how each action of insertion complies with 8200 and they are safe in the SR domain, well done, thanks!  :) And, I agree, the constraint that excludes other EH than SRH may limit the flexibility for future extension. Is this constraint so important? Besides, as opposed to Encap mode, Insertion mode can improve transfer efficiency, and has other advantages/shortcomings. So, I think we need to elaborate that as a kind of motivation to introduce Insertion mode. Because of Encap mode is in the main SRH draft now.  :) FYI, have a good day. Best regards, SING Moonlight Thoughts SING Team. Guangzhou, China Signature is customized by Netease Mail Master On 09/21/2019 12:54, Joel M. Halpern wrote: I see where the draft defines a set of constraints. The constraint that there be no other extension headers is a fairly drastic constraint, which would seem a cause for concern. Putting that aside however, the draft does not seem to provide any explanation for why insertion rather than additional encapsulation is used.  Particularly given the assumption that the MTU is large enough, it seems the encapsulation could be used for all insertion cases. Yours, Joel On 9/21/2019 12:34 AM, Darren Dukes (ddukes) wrote: > Hello everyone, we’ve just submitted an updated draft that explains why > SRH insertion is performed in an SR domain, how it is accomplished and > why it is safe within the SR domain. > > The authors look forward to your comments and suggestions on how to > improve this document. > > Thanks! >    Darren (on behalf of the authors) > >> Begin forwarded message: >> >> *From: *<[email-masked] <mailto:[email-masked]>> >> *Subject: **New Version Notification for >> draft-voyer-6man-extension-header-insertion-07.txt* >> *Date: *September 21, 2019 at 12:20:13 AM EDT >> >> >> A new version of I-D, draft-voyer-6man-extension-header-insertion-07.txt >> has been successfully submitted by Darren Dukes and posted to the >> IETF repository. >> >> Name:draft-voyer-6man-extension-header-insertion >> Revision:07 >> Title:Insertion of IPv6 Segment Routing Headers in a Controlled Domain >> Document date:2019-09-20 >> Group:Individual Submission >> Pages:13 >> URL: >> https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt >> Status: >> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/ >> Htmlized: >> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07 >> >> Abstract: >>   Traffic traversing an SR domain is encapsulated in an outer IPv6 >>   header for its journey through the SR domain. >> >>   To implement transport services strictly within the SR domain, the SR >>   domain may require insertion or removal of an SRH after the outer >>   IPv6 header of the SR domain.  Any segment within the SRH is strictly >>   contained within the SR domain. >> >>   The SR domain always preserves the end-to-end integrity of traffic >>   traversing it.  No extension header is manipulated, inserted or >>   removed from an inner transported packet.  The packet leaving the SR >>   domain is exactly the same (except for the hop-limit update) as the >>   packet entering the SR domain. >> >>   The SR domain is designed with link MTU sufficiently greater than the >>   MTU at the ingress edge of the SR domain. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> <http://tools.ietf.org>;. >> >> The IETF Secretariat >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [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: "Voyer, Daniel" <[email-masked]>
Date: Sat, 21 Sep 2019 17:01:44 +0000

Hi Joel, 

Sent from my mobile

> On Sep 21, 2019, at 00:54, Joel M. Halpern <[email-masked]> wrote:
> 
> The constraint that there be no other extension headers is a fairly drastic constraint, which would seem a cause for concern.
> 
> Putting that aside however, the draft does not seem to provide any explanation for why insertion rather than additional encapsulation is used.  Particularly given the assumption that the MTU is large enough, it seems the encapsulation could be used for all insertion cases.
> 
DV: correct, you can use encapsulations but at the cost of 40bytes overhead. Running an operators backbone, with a widespread among of use cases, you need those bytes..

> Joel
Regards
Dan
>>> *Subject: **New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt*
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>>> 
>>> The IETF Secretariat
>>> 
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Sep 2019 10:04:02 -0700

Some comments:

Most of the constraints listed section 2.2 should be specified as
normative requirements.

"SR domain link MTU is sufficiently greater than the MTU at the
ingress edge of the SR domain..." should be the requirement: "The MTU
for all paths in the domain MUST be large enough to accommodate the
maximum length of an inserted SRH"

Also, for sizing MTU some guidance to the operator to determine what
the maximum length SRH they will ever need would be useful.

"Within the context of this document and the described SRH use-case
within the SR domain, the SR domain can guarantee that SRH is the sole
extension header after the outer IPv6 header." should be the
requirement "An SRH MUST NOT be inserted into a packet that already
has extension headers"

"All traffic within the SR domain has IPv6 source and destination
address within the SR domain." should be requirement: "All traffic
within the SR domain MUST have an IPv6 source and destination address
that is within the SR domain."

Similarly, "Only traffic sourced from and destined to nodes in the SR
domain may have an SRH inserted." could be: "Traffic sourced from or
destined to a node outside of the SR domain MUST NOT have an SRH
inserted."

About "IPv6 encapsulation and optional insertion of SRH at the SR
domain ingress edge generates a new IPv6 packet." and "IPv6
encapsulation and SRH insertion at SR Domain ingress edge."

This is a bit confusing in the use of the word "insertion" in the
context of encapsulation, and on first read it seemed to be allowing
SRH insertion at ingress into the domain (without encapsulating).
Instead of saying "insertion" here, maybe something like "the SRH may
be included when encapsulating". That is, reserve the term "insertion"
to explicitly mean when SRH is being inserted into an existing IPv6
packet without encapsulating.

The attribution problem hasn't been addressed. I imagine it may be
possible to put the address of the node inserting an SRH somewhere in
the header in order to provide proper attribution.

Tom

Tom

On Fri, Sep 20, 2019 at 9:35 PM Darren Dukes (ddukes) <[email-masked]> wrote:
> From: <[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Sep 2019 10:16:01 -0700

> DV: correct, you can use encapsulations but at the cost of 40bytes overhead. Running an operators backbone, with a widespread among of use cases, you need those bytes..

Daniel,

The overhead difference is more like 24 bytes since the destination IP
address would need to be in the SID list in insertion case. The source
address in encapsulation is useful to provide proper attribution. In
any case, the argument that overhead matters would be much more
convincing if the segment routing header itself was sparing in
overhead (carrying a list of 16 byte IPv6 addresses is a lot of
overhead).

Tom

---

From: Mark Smith <[email-masked]>
Date: Sun, 22 Sep 2019 10:58:18 +1000

On Sun, 22 Sep 2019, 03:02 Voyer, Daniel, <[email-masked]> wrote:

> used.  Particularly given the assumption that the MTU is large enough, it
> seems the encapsulation could be used for all insertion cases.
> >
> DV: correct, you can use encapsulations but at the cost of 40bytes
> overhead. Running an operators backbone, with a widespread among of use
> cases, you need those bytes..
>

Clear evidence that 128 bit SIDs are the actual problem.

These SIDs can literally encode more values than the entire possible IPv6
unicast address space can. There can literally be more SID values than
there will ever be IPv6 hosts for all time.

That can't be a requirement if SR can operate adequately operate over MPLS
with only 20 bit SIDs. Surely 16 or 32 bit SIDs would be adequate when
operating SR over IPv6.

Give up these massive 128 bit SIDs for a much more functionally appropriate
size and you can use RFC8200 compliant operations without any overhead
concerns.

> SRH insertion is performed in an SR domain, how it is accomplished and why
> it is safe within the SR domain.
> >>> A new version of I-D,
> draft-voyer-6man-extension-header-insertion-07.txt
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Mark Smith <[email-masked]>
Date: Sun, 22 Sep 2019 11:24:38 +1000

> packet without encapsulating.

The entire use of the word "insertion" is incorrect if the ID is now only
proposing encapsulation/tunnelling to carry transit traffic across the SR
domain.

According to Google, the meaning of "insert" is:

place, fit, or push (something) into something else.

The process of encapsulation, by creating a new IPv6 packet, and creating
one or more new EHs following it (which may be derived from EHs received
from somewhere else), and then carrying the existing packet unmodified as
payload in the new packet, does not involve any "place, fit, or push
(something) *into* something else".

Encapsulation is addition to the outside of the existing.

I don't really understand why people are seeming to want to cling to using
the word insertion, despite it being entirely inaccurate when using
encapsulation.

> the header in order to provide proper attribution.

At each point where a function using the SRH needs to be performed, that is
one segment's and point, and another segment's start point.

They would also be an IPv6 tunnel end point and another tunnel's start
point (segments and tunnels are 1:1). The new outgoing segment tunnel
header would have the local device as its source address, providing
attribution.

In other words a sequence of segments in an SR over IPv6 network would be a
sequence of distinct IPv6 tunnels, 1:1 for the entire path.

This model is entirely compliant with RFC 8200, and as tunnels end points
are hosts using RFC 8200's definitions, host EHs such as Destination
Option, or AH and ESP can be used in an RFC 8200 compliant manner.

Regards,
Mark.

> > Subject: New Version Notification for

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 22 Sep 2019 15:52:17 +0200

Hey Mark,

> proposing encapsulation/tunnelling to carry transit traffic across the SR

That is not what the discussed draft says. The draft proposes encapsulation
on ingress edge of the domain, decapsulation on the egress edge of the
domain AND freedom of insertion, deletion (and IMHO also it should also add
modification) of any SRH(s) within the encapsulated header at any point in
the domain. Yes there can be more then one SRH per current notion of the
draft too during the protection.

 The new outgoing segment tunnel header would have the local device as its
> source address, providing attribution.
>

Who told you that ?

Just please read network programming draft and you see that "swapping"
source address is never the case at segment end points:

Quote:

      Node 8 originates packets with the received SRH with HMAC TLV.

   P15:(*A8*,S5)(A9,S6,S7,S5;SL=3;HMAC)

   Node 5 receives and verifies the HMAC for the SRH, then forwards the
   packet to the next segment

   P16:(*A8*,S7)(A9,S6,S7,S5;SL=2;HMAC)

   Node 6 receives

   P17:(*A8*,S6)(A9,S6,S7,S5;SL=1;HMAC)

   Node 9 receives

   P18:(*A8*,A9)(A9,S6,S7,S5;SL=0;HMAC)

Please notice that encapsulated packet by A8 has source address of A8.
And that never changes through the entire domain !

Are you now questioning the entire concept of SRv6 architecture ?

Just FYI all documents describing SRv6+ architecture and CRH also do
not swap source address at segment end nodes.

Ref draft-bonica-6man-comp-rtg-hdr-07 - Appendix A where src
*2001:db8::a* never changes.

> Option, or AH and ESP can be used in an RFC 8200 compliant manner.

See the issue you are missing is that even if one would follow strictly to
what you are recommending in SRv6 it is still not possible to enable TI-LFA
with SR in the domain as you can not just treat each PLR as Segment End
node.

Of course I guess you can question if TI-LFA with SRv6 is something IPv6
want to support with SR - but as there is some demand I guess more
rationale is required then just say "No".  And of course using SRH is one
way to encode TE topology for TI-LFA. There are other options too, but for
now this discussion is about use of SRv6 technology to achieve that.

Kind regards,
R.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Sep 2019 00:36:46 +0300

On 22/9/19 16:52, Robert Raszuk wrote:
[....]
> rationale is required then just say "No". 

It's the other way around: if anything, you need to make a case why you
want to break IPv6. The onus is on you.

Allowing EH insertion turns what was an e2e protocol into something else.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Sep 2019 01:01:55 +0300

On 22/9/19 16:52, Robert Raszuk wrote:
> Hey Mark,
> 
>  
> 
>     The entire use of the word "insertion" is incorrect if the ID is now
>     only proposing encapsulation/tunnelling to carry transit traffic
>     across the SR domain.
> 
> 
> That is not what the discussed draft says. The draft proposes
> encapsulation on ingress edge of the domain, decapsulation on the egress
> edge of the domain AND freedom of insertion, deletion (and IMHO also it
> should also add modification) of any SRH(s) within the encapsulated
> header at any point in the domain. Yes there can be more then one SRH
> per current notion of the draft too during the protection. 
> 
>      The new outgoing segment tunnel header would have the local device
>     as its source address, providing attribution.
> 
> 
> Who told you that ? 
> 

Curiously enough you seem to be specifying an architecture by breaking
that of the protocol it relies on.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Mon, 23 Sep 2019 17:08:44 +1000

On Sun, 22 Sep 2019 at 23:52, Robert Raszuk <[email-masked]> wrote:
>
> Hey Mark,
>
>
>>
>> The entire use of the word "insertion" is incorrect if the ID is now only proposing encapsulation/tunnelling to carry transit traffic across the SR domain.
>
>
> That is not what the discussed draft says. The draft proposes encapsulation on ingress edge of the domain, decapsulation on the egress edge of the domain AND freedom of insertion, deletion (and IMHO also it should also add modification) of any SRH(s) within the encapsulated header at any point in the domain. Yes there can be more then one SRH per current notion of the draft too during the protection.
>

Sigh, now you're inserting into the outer IPv6 packet. Still not allowed.

I'm getting off of this merry go around. I can't spend any more time on this.

This Internet Draft is a denial of service attack on the 6man working
group, exhausting resources that could be better spent elsewhere.

This ID has been submitted now 7 times, and despite how many times it
has been pointed out that EH insertion is prohibited, how RFC 8200 has
been specifically updated to be more explicit about it, how many times
I and others have pointed out the protocol, practical and operational
problems it causes, that is being ignored.

I'm not going to point out how CRH/SRv6 complies with RFC 8200. It
does, and if you don't understand how, then you'll need to read RFC
8200 more thoroughly.

>>  The new outgoing segment tunnel header would have the local device as its source address, providing attribution.
>
>
> Who told you that ?
>
> Just please read network programming draft and you see that "swapping" source address is never the case at segment end points:
>
> Quote:
>
>    P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC)
>
>    P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC)
>
>    Node 6 receives
>
>    P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC)
>
>    Node 9 receives
>
>    P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC)
>
>
>
> Please notice that encapsulated packet by A8 has source address of A8. And that never changes through the entire domain !
>
>
> Just FYI all documents describing SRv6+ architecture and CRH also do not swap source address at segment end nodes.
>
>
> Ref draft-bonica-6man-comp-rtg-hdr-07 - Appendix A where src 2001:db8::a never changes.
>
>
>> This model is entirely compliant with RFC 8200, and as tunnels end points are hosts using RFC 8200's definitions, host EHs such as Destination Option, or AH and ESP can be used in an RFC 8200 compliant manner.
>
>
> See the issue you are missing is that even if one would follow strictly to what you are recommending in SRv6 it is still not possible to enable TI-LFA with SR in the domain as you can not just treat each PLR as Segment End node.
>
> Of course I guess you can question if TI-LFA with SRv6 is something IPv6 want to support with SR - but as there is some demand I guess more rationale is required then just say "No".  And of course using SRH is one way to encode TE topology for TI-LFA. There are other options too, but for now this discussion is about use of SRv6 technology to achieve that.
>
> Kind regards,
> R.
>