Subject: WGLC - draft-ietf-spring-srv6-network-programming

From: <[email-masked]>
Date: Thu, 5 Dec 2019 17:15:26 +0000

Hello SPRING,

This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].

Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_________________________________________________________________________________________________________________________

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: Ron Bonica <[email-masked]>
Date: Thu, 5 Dec 2019 21:14:06 +0000

< Responding to the right email this time >

Bruno,

Please record the following as last call comments:

- https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY

- https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg

- https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk

- https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E

                                                   Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, December 5, 2019 12:15 PM
To: 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05__;!8WoA6RjC81c!WtdxYG2xSF_q2rpWnOYGhgrGW8yw7jzvLa8EiJUeP05yi3TdBSyI35n-pjc7gafR$>

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Dec 2019 09:14:54 +0800

Hello Bruno and all,

I don't think the issues discussed again and again in the earlier iterations have been addressed in this version to be WGLCed.

Thanks for Durren's recap as follows.
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o
[2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo
[2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c
[2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI
[2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E

And Ron's recap as follows.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: [email-masked]
Date: 2019-12-06 01:15
To: 'SPRING WG List'
CC: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming
Hello SPRING, This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) Thank you,Bruno [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Dec 2019 08:15:51 +0000

In addition to the below,

In Section 2:

In this version of the document, we assume that there are no other
   extension headers than the SRH.  These will be lifted in future
   versions of the document.

If the document is going to last call – what future versions and are plans to lift these restrictions going to come to fruition before this goes to last call or in separate rfc’s that update this document?  This is of concern because it assumes that there is no hop-by-hop option header, no fragment header, no ESP header, no AH header, no MH header etc etc.  Effectively making the use of this incompatible with things explicitly defined in section 4 of RFC8200, and which may run foul of the working group charter which states that SPRING should be avoiding making changes which define things incompatible with existing deployments.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, 6 December 2019 04:15
To: [email-masked]; [email-masked]
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hello Bruno and all,

Thanks for Durren's recap as follows.
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o<https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o>
[2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo<https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo>
[2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c<https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c>
[2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI<https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI>
[2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E<https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E>

And Ron's recap as follows.
- https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY<https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY>
- https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg<https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg>
- https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk<https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk>
- https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E<https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E>

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]>
Date: 2019-12-06 01:15
To: 'SPRING WG List'<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf..org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05>

Thank you.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2019 16:14:48 +0100

Hi,

> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

I think there are plenty of already documented reasons that this draft should have never been thrown into WGLC in the first place.

Therefore I do not consent.
Sander

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 13:22:31 -0300

> I think there are plenty of already documented reasons that this draft should have never been thrown into WGLC in the first place.

+1

Also, as noted, I support Ron Bonica's WGLC comments.

Thanks,
-- 
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: Fri, 6 Dec 2019 15:50:50 -0300

>    versions of the document.

Can the authors clarify what this means?

That this mean "this will not work as expected if there are other EHs"?
If not, why the statement?  If yes, what happens if you do receive
packets with other EHs (say, FH, IPsec, or others)?

Thanks,

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 9 Dec 2019 15:20:33 +0000

Andrew,

You seem to be reading an outdated version of the document.  That text (and the related restrictions) have been removed since version -02.

Please read the revision that is being last-called (-05) and let me know whether you have any comment.

Thanks,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Friday, 6 December 2019 at 09:16
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Friday, 6 December 2019 at 09:16

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Andrew Alston <[email-masked]>
Date: Mon, 9 Dec 2019 17:19:06 +0000

Thanks Pablo – mistake om my part – and for this I apologise.

So just to confirm – can you confirm that with that text removed – you seen no issues using the additional EH’s as currently defined by other RFC’s in conjunction with this technology?  I ask this because considering that statement in the draft – I’d like some confirmation that this has been considered, and it is not just a removal of a piece of text

Thanks

Andrew

From: spring <[email-masked]> on behalf of "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Monday, 9 December 2019 at 18:20
To: Andrew Alston <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Thanks,
Pablo.

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.

---

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

Bruno,

On 5/12/19 12:15, [email-masked] wrote:
[....]>
> This email starts a two weeks Working Group Last Call on
> draft-ietf-spring-srv6-network-programming [1].
> 
>  
> 
> Please read this document if you haven't read the most recent version,
> and send your comments to the SPRING WG list, no later than December 20.
> 
>  
> 
> You may copy the 6MAN WG for IPv6 related comment, but consider not
> duplicating emails on the 6MAN mailing list for the comments which are
> only spring specifics.
> 
>  
> 
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
> 
> This may help avoiding that the thread become specific to this point and
> that other points get forgotten (or that the thread get converted into
> parallel independent discussions)

Penultimate Segment Popping describes/specifies the removal of a SRH at
a place other than the final destination of the packet.

Such behavior violates RFC8200, which specifies:

   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 Destination Address field
   of the IPv6 header.

Note, of course, that the reference of "Destination Address" in RFC8200
is clearly the final destination of the packet -- for instance, RFC8200
does not specify any routing header type, and hence the meaning is
unambiguous (there's no destination other than the final destination of
the packet).

This is of course in line with IPv6 being and end-to-end protocol, and
crucial for other related mechanisms to work as expected (such as IPsec
AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.

So, in order to proceed with the document, there are multiple options
forward:

1) Just remove the corresponding text/behavior

2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
re-encap)

3) Do the necessary standards work to update RFC8200, such that it
allows this sort of behavior, and only ship the network-programming
draft for publication when at least 6man has consensus to proceed on
that path.

P.S.: I will go through the document once again... but the same
reasoning should be applied to any EH-insertion/removal at a place other
than the source of the packet or its final destination.

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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Dec 2019 17:55:31 -0500

<no hats>

> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

I will happily admit that I haven't been following the discussions, so
apologies in advance - I'm guessing I'm missing something really
obvious, so please point me at other documents / email threads where
this has already been answered...

RFC5095 deprecated IPv6 RH0 due to some serious security issues - it
was possible for an attacker to send traffic containing "instructions"
to make a packet ping-pong between two interfaces, steer it down
specific links, etc.

It feels to me like this re-introduces similar (and potentially more
scary) issues -- what's to stop an attacker spoofing traffic
containing a bunch of SIDs which decapsulate, push a packet into
another FIB, End.DT2M, etc?

I went to look in the Security Considerations section, but, well, the
document doesn't seem to have one?...
The word Security appears 3 times in the document - one in the section
title ("7. Basic security for intra-domain deployment"), once in the
Index, and once simply punting the reader to Section 5.1 of the SRH
document ("Future documents will detail inter-domain security
mechanisms for
 SRv6 ").

Expecting *everyone* who deploys this to perfectly apply filters which
blocks ingress traffic everywhere where a packet could enter a domain
feels like an accident just waiting to happen
Again, I'm guessing that I'm missing something obvious, and that the
entire security isn't premised on that - please point me to where this
is addressed.

"With great power comes great responsibility"
    -- sudo, via Peter Parker.

W

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

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

Hi Pablo, authors

"4.13.  End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps"
is clear that an IPv6 encapsulation is performed. e.g with the below text
"  S14.   Push a new IPv6 header with its own SRH containing B"

However, I find that "4.14.  End.B6.Encaps.Red: [...] with reduced SRH" is a little less clear on that. E.g.,

"This is an optimization of the End.B6.Encaps behavior."
Looks good.

"   The new SRH is created as described in Section 4.1.1 of [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>]."
Is not that specific. Could you please explicitly add that an IPv6 outer header is added ?

"  End.B6.Encaps.RED  [...] with reduced SRH insertion SRv6 instantiation of a Binding SID"
Does not looks good.
Please remove any reference to "SRH insertion". "IPv6 encapsulation with an SRH header" would be preferred.

"     4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps  20
     4.14<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.14>. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . .  21<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-21> >

May be
OLD: End.B6.Encaps.Red: [...] with reduced SRH
NEW: End.B6.Encaps.Red: End.B6.Encaps with reduced SRH

(this does fit in a single line)

Thank you,
Best regards,
--Bruno

From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 5, 2019 6:15 PM
To: 'SPRING WG List'
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

Thank you.

---

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

Fernando,

Thank you for spelling out your comment, plus on the WGLC thread.
More in-line

> is clearly the final destination of the packet -- for instance, RFC8200

I hear and can understand your reading of RFC8200.
At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".
Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.
I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

> 1) Just remove the corresponding text/behavior

That is indeed one option. But as of today, this is not my assumption.
 
> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,

SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.
 
> draft for publication when at least 6man has consensus to proceed on

Not the preferred path as of today.
 
> than the source of the packet or its final destination.

It looks to me that SRH insertion and SRH removal are to be treated differently. The difference been that for SRH insertion, in general the node doing insertion is any node on the path hence not specifically a node ' identified in the Destination Address field of the IPv6 header." While for and End* PSP behavior, the node doing SRH removal is a node '' identified in the Destination Address field of the IPv6 header.". Or at minimum this seems a possible interpretation of RFC 8200.
In all cases, while this is sorted out, let's treat both as different.

Thank you,
--Bruno

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:16:13 -0500

Bruno,

> I hear and can understand your reading of RFC8200.

Could you please check RFC8200, and tell me what other possible
interpretation of "Destination Address" you might have, in the context
of RFC8200.

RFC8200 does not even specify any routing header types. SO...where's the
ambiguity?

> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".

No, I argue that there is not. IN fact, I argue that folks have been
following that strategy for way too long, and that's quite frustrating.

> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.

The quoted text is from RFC8200. In the context of RFC8200 the
Destination Address can only contain the ultimate destination of the
packet. Where's the ambiguity?

And let me ask you, as chair, another question, that will lead you to
the same place: is IPv6 and end to end protocol?

The fact that I may claim that RFC8200 contains a receipe for BBQ does
not actually mean that that's the case.

> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

For the record, I think this is a major issue that should be cleared
before it can be claimed that there is consensus to request publication
of this document.

> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a w…

It's about SRH removal, which is also forbiden by RFC8200.

> Not the preferred path as of today.

Yes, it should be evident that it seems the preferred path has been
(starting with EH insertion at the time) to circumvent existing
specifications.

> It looks to me that SRH insertion and SRH removal are to be treated differently. 

I don't see how or why. Both violate the same requirement in RFC8200.

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Dec 2019 19:49:07 -0500

Fernando, I really wish I could agree with you.
But I can't.

In 8200, it is clear that the meaning fo "Destination Address" for an 
IPv6 packet is the value placed in the IPv6 destination address field. 
the fact that if we had looked ahead we might have said something 
different does not change what words we chose to use.  If I am going to 
insist (as I have in other contexts) that other folks live with the 
words we compromised on in 8200, then I have to live myself with the 
words we compromised on in 8200.

I have concerns about whether PSP is a good design.  I am trying to 
write a useful note on the topic.  (And without such a note, I can not 
expect anyone to care about thoughts in my head.)   But I can not and 
will not claim that PSP violates RFC 8200.

Yours,
Joel

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Dec 2019 19:51:36 -0500

> before it can be claimed that there is consensus to request publication

[ .. and once again / still with no hats ]

I'd suggest that *everyone* read RFC7282 - "On Consensus and Humming
in the IETF" - being a Pete Resnick document, it is clear, concise and
a pleasant read.

Unfortunately it's also descriptive, rather than prescriptive, and so
people may take away different things from it, but it's *still* a
useful read...

W

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 01:55:32 +0100

Bravo Joel !

On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern <[email-masked]> wrote:

> >> At minimum, I think that we can agree that there is another reading, as
> expressed by other WG participants, and hence I disagree with "of course".
> >
> >> Personally, I understand "Destination Address" as "Destination Address
> field of the IPv6 header." as indicated explicitly in the text quoted.
> >
> >> I'm fine with having this clarified with 6MAND chairs and AD. That been
> said, the Internet AD would have an opportunity to DISCUSS this.
> >
> >>> AH). Please also check:
> draft-smith-6man-in-flight-eh-insertion-harmful.
> >>>
> >> We are talking SRH removal. I'm assuming that you are referring to PSP.
> My understanding is that this function (PSP) is to distribute the
> (forwarding plane) load between the PSP and the USP. In a way similar to
> MPLS PHP. But in all cases, this is not about SRH insertion.
> >
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

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

+1
Kindly remind that, there are ‘final destination’ wording 5 times in RFC8200. The 8200 is aware of difference of ‘destination’ and ‘final destination’.

         Line 375:       note 3: for options to be processed only by the final destination
         Line 443:    packet's final destination.  When an Authentication header is present
         Line 576:                           before reaching the final destination.
         Line 650:    present, the Destination Address of concern is that of the final
         Line 838:          The Fragment header is not present in the final, reassembled
         Line 1130:          Address used in the pseudo-header is that of the final

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, December 11, 2019 8:56 AM
To: Joel M. Halpern <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Bravo Joel !

On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
Fernando, I really wish I could agree with you.
But I can't.

Yours,
Joel

On 12/10/2019 6:16 PM, Fernando Gont wrote:
> Bruno,
>
> On 10/12/19 13:18, [email-masked]<mailto:[email-masked]> wrote:
>> Fernando,
>>
>>> On 5/12/19 12:15, [email-masked]<mailto:[email-masked]> wrote:
>>> [....]>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Dec 2019 17:43:51 -0800

> words we compromised on in 8200.
Joel,

That might be the wording, but don't believe that was the intent. The
real intent is revealed by some of the earlier text that said
(draft-ietf-6man-rfc2460bis-07):

"The insertion of Extension Headers by any node other than the source
of the packet breaks PMTU-discovery and can result in ICMP error
messages being sent to the source of the packet that did not insert
the header."

That is true, and breaking ICMP is an issue that has been raised
repeatedly. It also breaks AH as pointed out. Furthermore, if RFC8200
allows SRH insertion to occur, then we'd have to accept that it allows
ANY type EH insertion (except maybe fragmentation?) to occur at any
destination address! Not only that, we also need to accept that this
would allow NAT devices to insert EH when the destination address is
the NAT address.

So the possibility that destination address wasn't spelled out as
being final destination seems to be an unfortunate omission, but even
so, that omission doesn't somehow magically make EH insertion robust
or mitigate the problems of EH insertion that have already been
discussed. Neither does it provide the rationale why encapsulation
with the EH can't be used instead which is clearly the option that
most closely adheres to the Robustness principle.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Dec 2019 21:18:52 -0500

Tom, I was and am commenting on OSP.  Header insertion is a separate, lo8sely related, topic.I think it is quite important that we use the words we ended up with, both when they support what we want and when they do not.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Tom Herbert <[email-masked]> Date: 12/10/19  20:44  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Fernando Gont <[email-masked]>, SPRING WG List <[email-masked]>, [email-masked] Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming On Tue, Dec 10, 2019 at 4:49 PM Joel M. Halpern <[email-masked]> wrote:>> Fernando, I really wish I could agree with you.> But I can't.>> In 8200, it is clear that the meaning fo "Destination Address" for an> IPv6 packet is the value placed in the IPv6 destination address field.> the fact that if we had looked ahead we might have said something> different does not change what words we chose to use.  If I am going to> insist (as I have in other contexts) that other folks live with the> words we compromised on in 8200, then I have to live myself with the> words we compromised on in 8200.>Joel,That might be the wording, but don't believe that was the intent. Thereal intent is revealed by some of the earlier text that said(draft-ietf-6man-rfc2460bis-07):"The insertion of Extension Headers by any node other than the sourceof the packet breaks PMTU-discovery and can result in ICMP errormessages being sent to the source of the packet that did not insertthe header."That is true, and breaking ICMP is an issue that has been raisedrepeatedly. It also breaks AH as pointed out. Furthermore, if RFC8200allows SRH insertion to occur, then we'd have to accept that it allowsANY type EH insertion (except maybe fragmentation?) to occur at anydestination address! Not only that, we also need to accept that thiswould allow NAT devices to insert EH when the destination address isthe NAT address.So the possibility that destination address wasn't spelled out asbeing final destination seems to be an unfortunate omission, but evenso, that omission doesn't somehow magically make EH insertion robustor mitigate the problems of EH insertion that have already beendiscussed. Neither does it provide the rationale why encapsulationwith the EH can't be used instead which is clearly the option thatmost closely adheres to the Robustness principle.Tom> I have concerns about whether PSP is a good design.  I am trying to> write a useful note on the topic.  (And without such a note, I can not> expect anyone to care about thoughts in my head.)   But I can not and> will not claim that PSP violates RFC 8200.>> Yours,> Joel>> On 12/10/2019 6:16 PM, Fernando Gont wrote:> > Bruno,> >> > On 10/12/19 13:18, [email-masked] wrote:> >> Fernando,> >>> >> Thank you for spelling out your comment, plus on the WGLC thread.> >> More in-line> >>> >>> Bruno,> >>>> >>> On 5/12/19 12:15, [email-masked] wrote:> >>> [....]>> >>>> This email starts a two weeks Working Group Last Call on> >>>> draft-ietf-spring-srv6-network-programming [1].> >>>>> >>>>> >>>>> >>>> Please read this document if you haven't read the most recent version,> >>>> and send your comments to the SPRING WG list, no later than December 20.> >>>>> >>>>> >>>>> >>>> You may copy the 6MAN WG for IPv6 related comment, but consider not> >>>> duplicating emails on the 6MAN mailing list for the comments which are> >>>> only spring specifics.> >>>>> >>>>> >>>>> >>>> If you are raising a point which you expect will be specifically debated> >>>> on the mailing list, consider using a specific email/thread for this point.> >>>>> >>>> This may help avoiding that the thread become specific to this point and> >>>> that other points get forgotten (or that the thread get converted into> >>>> parallel independent discussions)> >>>> >>> Penultimate Segment Popping describes/specifies the removal of a SRH at> >>> a place other than the final destination of the packet.> >>>> >>> Such behavior violates RFC8200, which specifies:> >>>> >>     > 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 Destination Address field> >>     > of the IPv6 header.> >>>> >>> Note, of course, that the reference of "Destination Address" in RFC8200> >>> is clearly the final destination of the packet -- for instance, RFC8200> >>> >> I hear and can understand your reading of RFC8200.> >> > Could you please check RFC8200, and tell me what other possible> > interpretation of "Destination Address" you might have, in the context> > of RFC8200.> >> > RFC8200 does not even specify any routing header types. SO...where's the> > ambiguity?> >> >> >> >> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".> >> > No, I argue that there is not. IN fact, I argue that folks have been> > following that strategy for way too long, and that's quite frustrating.> >> >> >> >> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.> >> > The quoted text is from RFC8200. In the context of RFC8200 the> > Destination Address can only contain the ultimate destination of the> > packet. Where's the ambiguity?> >> > And let me ask you, as chair, another question, that will lead you to> > the same place: is IPv6 and end to end protocol?> >> >> > The fact that I may claim that RFC8200 contains a receipe for BBQ does> > not actually mean that that's the case.> >> >> >> >> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.> >> > For the record, I think this is a major issue that should be cleared> > before it can be claimed that there is consensus to request publication> > of this document.> >> >> >> >>> >>> does not specify any routing header type, and hence the meaning is> >>> unambiguous (there's no destination other than the final destination of> >>> the packet).> >>>> >>> This is of course in line with IPv6 being and end-to-end protocol, and> >>> crucial for other related mechanisms to work as expected (such as IPsec> >>> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.> >>>> >>> So, in order to proceed with the document, there are multiple options> >>> forward:> >>>> >>> 1) Just remove the corresponding text/behavior> >>> >> That is indeed one option. But as of today, this is not my assumption.> >>> >>> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,> >>> re-encap)> >>> >> SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.> >> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.> >> > It's about SRH removal, which is also forbiden by RFC8200.> >> >> >> >> >>> 3) Do the necessary standards work to update RFC8200, such that it> >>> allows this sort of behavior, and only ship the network-programming> >>> draft for publication when at least 6man has consensus to proceed on> >>> that path.> >>> >> Not the preferred path as of today.> >> > Yes, it should be evident that it seems the preferred path has been> > (starting with EH insertion at the time) to circumvent existing> > specifications.> >> >> >> >>> >>> P.S.: I will go through the document once again... but the same> >>> reasoning should be applied to any EH-insertion/removal at a place other> >>> than the source of the packet or its final destination.> >>> >> It looks to me that SRH insertion and SRH removal are to be treated differently.> >> > I don't see how or why. Both violate the same requirement in RFC8200.> >> >> > Thanks,> >>> --------------------------------------------------------------------> IETF IPv6 working group mailing list> [email-masked]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 21:23:10 -0500

Joel,

> IPv6 packet is the value placed in the IPv6 destination address field.

One could indeed argue that the wording in RFC8200 could have been
better. However, the intent is clear, and also since RFC8200 does not
specify any routing header type, in the context of RFC8200 packets
there's no possible destination other than the ultimate destination.

Maybe an errata is warranted.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 21:29:47 -0500

> Maybe an errata is warranted.

FWIW, Appendix B notes:

   o  Clarified that 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.

Thanks,

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 18:37:39 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Wednesday, December 11, 2019 12:16 AM
> 
> Bruno,
> 

Another interpretation is
"the node [...] identified in the Destination Address field of the IPv6 header."
https://tools.ietf.org/html/rfc8200#section-4

 Actually, that's verbatim the text from RFC 8200.

> RFC8200 does not even specify any routing header types. SO...where's the

- Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others.  And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated.
- Why have _you_ filled an errata against RFC 8200, in order to change the technical content of this section, if you don't agree that one may red " Destination Address field of the IPv6 header" as the IPv6 address present in the Destination Address field of the IPv6 header been received by the End node (or even sent by the source node)
https://www.rfc-editor.org/errata/eid5933

> No, I argue that there is not.IN fact, I argue that folks have been

That's not a question for a spring chair to answer.
I'm reading the sentence in RFC8200. If we can't agree on the meaning of this explicit sentence, I don't think that discussing philosophical r religious question is going to help.

> not actually mean that that's the case.

You do realize that your above sentence also applies to yourself? So how is this helping to progress?
Can we please focus on the RFC8200 sentence?  I'm really trying to understand your point. 
Let's stick to the texts of documents.

> before it can be claimed that there is consensus to request publication

OK, this is recorded. 
> I don't see how or why. 

SRH insertion is done by a node, on the path, which is not the destination of the IPv6 addresses.
SRH removal is done by a node which is receiving the packet because it's IPv6 address is in the destination of the IPv6 packet.

> Both violate the same requirement in RFC8200.

We are not having a conversation, so let's not repeats the same point again and again.

Your opinion has been noted. So does opinions on this same point expressed by other wg participants.

---

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

Andrew,

No big deal. :-)

In reply to your question: I confirm that draft-ietf-spring-srv6-network-programming does not present any restriction to combine the SRH in conjunction with other EHs from other RFCs.

Thanks,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Monday, 9 December 2019 at 18:19
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Thanks

Andrew

Andrew,

Thanks,
Pablo.

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.