Subject: Net-PGM does NOT contain insertion behavior : was: - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 9 May 2020 13:21:23 +0000

Hi Joel, the WG,

Changing the subject to highlight what Joel mentioned.

draft-ietf-spring-srv6-network-programming does NOT contain text related to SRH insertion.

SRH insertion in the context of network programming is an individual document (https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-insertion-02), which relies on considerations described in a 6man document, https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/ (-00 was submitted in March 2017).

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Friday, May 8, 2020 at 7:33 PM
To: Gyan Mishra <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

The SRv6 PGM document that was approved does not do arbitrary insertion.
  It does the very specific PSP removal.  I think it inappropriate for
us to say that given that this one piece was allowed, anything and
everything should be allowed.

Also, it is normal for RFCs to be understood to be only applicable going
forward.  The most that should be said about PSP in this draft
explicitly would be a note indicating that the PSP behavior predates
this, and is not affected by it.

And even that much would wait on the resolution of the pending appeal on
the topic.

Yours,
Joel

On 5/8/2020 7:27 PM, Gyan Mishra wrote:

Given that SRv6 PGM draft has left the station awaiting publication I
think the most prudent recourse for 6MAN is to grant the exception for
SRV6 technology to allow insertion and removal on any transit node
within the carriers administrative domain.

https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

Document      Type                      Active Internet-Draft (spring WG
<https://datatracker.ietf.org/wg/spring/><https://datatracker.ietf.org/wg/spring/%3e>)
           Last updated                      2020-04-14 (latest revision 2020-03-27)
           Replaces                              draft-filsfils-spring-srv6-network-programming
<https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/>
           Stream                  IETF
           Intended RFC status                        Proposed Standard
           Formats                                 plain text
<https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.txt>
   xml
<https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.xml>
   pdf
<https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-15.pdf> htmlized
(tools)
<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15>
   htmlized
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15> bibtex
<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/bibtex>
Stream            WG state <https://datatracker.ietf.org/help/state/draft/ietf>
Submitted to IESG for Publication
           Document shepherd                       Bruno Decraene

In the verbiage as to reasons why this being allowed is that SRv6 would
always be used in a closed domain with standard security protection
mechanisms at ingress and egress of the domain.  Domain definition would
have to be defined as a carriers administratrative domain where the
carriers transport network could span multiple ASs that are inter
connected via SR-TE bsid or inter-as L3 vpn.

One caveat loophole does exist is that inter administrative domain
intent based SR flows would also be allowed so in theory you could have
a chain of SRV6 domains over the internet or even private inter
connected domains so then maybe not bother with the domain concept as it
really goes out the window.

So then it’s just an exception to allow SRv6 to do as they please as
impossible to control at that point so any and all use cases of SRv6
would be granted the exception.

As Robert mentioned that it’s the carriers domain so they have to take
care of any security issues related to AH on the SRv6 outer IPV6
transport header.

Also as noted by Robert that all customer traffic is kept in tact and
not altered and that no insertion or removal of any EH headers occurs to
the inner header customer payload.  So no impact to customers use of AH
etc as that is remains unaltered.

Thanks

Gyan

On Fri, May 8, 2020 at 7:06 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:

     Hi Philip,

     Sounds very reasonable.

     IMO what is needed here is a short spec which would explicitly call
     out the case of using IPv6 as transport layer. Then it would allow
     the transport owner sufficient flexibility (insertion, modification,
     deletion) into applied by his own ingress new IPv6 header at any
     transit hop he seems required. Ultimate goal is to deliver carried
     payload (here original IPv6 or IPv4 packets) via a given network the
     best quality possible.

     Thx a lot,
     Robert.

     On Sat, May 9, 2020 at 12:42 AM Philip Homburg
     <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:

          >Now comes the topic of an additional hander mangling even by
         nodes which
          >are not intermediate destinations, yet all within transit
         network.

         So this is the key point. RFC 8200 applies to all IPv6 packets.
         So if
         RFC 8200 allows additional header mangling, then that can happen
         in lots of
         other places as well, which is quite undesirable.

         So RFC 8200 has to state that in general this sort of thing
         cannot happen.
         Next we can update RFC 8200 with a narrowly crafted exception
         tailored to
         this use case.

         We have two possibilities:
         - either RFC 8200 allows mangling by hops in a routing header.
         In that
            case we have a problem that needs to be fixed while creating
         an exception
            for segment routing, or
         - RFC 8200 does not allow this kind of mangling and we need to
         create an
            exception for segment routing.

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

--

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

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

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 11:06:02 -0300

> draft-ietf-spring-srv6-network-programming does NOT contain text related 

It contains text about header removal, which is in violation of RFC8200.

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 9 May 2020 15:11:09 +0000

Hi,

As discussed in detail during the net-pgm LC and documented in https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-4.16.1, accordingly:

·         [draft-ietf-spring-srv6-network-programming] defines segment behaviors solely within the context of the RFC8402 and RFC8754 section 5 where the Intra SR Domain Deployment Model is defined. Within the SR Domain the end to end behavior programmed by the source SR node in the SRH is deterministic.

  *   The source SR node learns, via a control plane, the behaviors supported by the endpoints and the segments bound to these behaviors.  The source SR node fully controls the delivery of any payload to any destination within the SR Domain.  Knowing the capability of that destination, it only includes behaviors at the penultimate segment endpoint node that are compatible with the ultimate segment endpoint (the destination within the SR Domain).
  *   PSP is an optional behavior.

·         “PSP behavior does not contravene Section 4 of [RFC8200]<https://tools.ietf.org/html/rfc8200#section-4> because the current destination address of the incoming packet is the address of the node executing the PSP behavior.”
In other words:

  *   The Pen-ultimate endpoint only advertises the PSP if he wants to offer it.
  *   If it does, then it binds a specific segment to that behavior.
  *   The source only choses PSP behavior if he wants that behavior.
  *   The source cares for the packet to reach the destination.

·         The source would never build a network program with a PSP flavor if there was a risk at the destination.
Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Fernando Gont <[email-masked]>
Date: Saturday, May 9, 2020 at 10:08 AM
To: "Zafar Ali (zali)" <zali=[email-masked]>, "Joel M. Halpern" <[email-masked]>, Gyan Mishra <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Net-PGM does NOT contain insertion behavior : was: - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

draft-ietf-spring-srv6-network-programming does NOT contain text related
to SRH insertion.

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 May 2020 12:48:50 -0300

Zafar,

It is interesting that you seem to believek that explaining why 
draft-ietf-spring-srv6-network-programming violates RFC8200 changes the 
fact that it violates RFC8200.

What I had to say, I said it during the WGLC of this document -- and it 
was dismissed, IMO. It is now time for the IESG to make their own 
judgement about this and the other technical aspects, as well as about 
the associated procedural issues.

I will weigh in if there's a need to do so in a eventual new WGLC, or in 
the corresponding IETF LC.

Until then, I'm done with this thread.

Thanks,
Fernando

On 9/5/20 12:11, Zafar Ali (zali) wrote:
> Hi,
> 
> As discussed in detail during the net-pgm LC and documented in 
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-4.16.1, 
> accordingly:
> 
> ·[draft-ietf-spring-srv6-network-programming] defines segment behaviors 
> solely within the context of the RFC8402 and RFC8754 section 5 where the 
> Intra SR Domain Deployment Model is defined. Within the SR Domain the 
> end to end behavior programmed by the source SR node in the SRH is 
> deterministic.
> 
>   * The source SR node learns, via a control plane, the behaviors
>     supported by the endpoints and the segments bound to these
>     behaviors.  The source SR node fully controls the delivery of any
>     payload to any destination within the SR Domain.  Knowing the
>     capability of that destination, it only includes behaviors at the
>     penultimate segment endpoint node that are compatible with the
>     ultimate segment endpoint (the destination within the SR Domain).
> ·“PSP behavior does not contravene Section 4 of [RFC8200] 
> <https://tools.ietf.org/html/rfc8200#section-4> because the current 
> destination address of the incoming packet is the address of the node 
> executing the PSP behavior.”
> 
> In other words:
> 
> ·The source would never build a network program with a PSP flavor if 
> there was a risk at the destination.
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *ipv6 <[email-masked]> on behalf of Fernando Gont 
> <[email-masked]>
> *Date: *Saturday, May 9, 2020 at 10:08 AM
> *To: *"Zafar Ali (zali)" <zali=[email-masked]>, "Joel M. 
> Halpern" <[email-masked]>, Gyan Mishra <[email-masked]>
> *Cc: *6man WG <[email-masked]>
> *Subject: *Re: Net-PGM does NOT contain insertion behavior : was: - Re: 
> some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
> 
> e-mail: [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>