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

["Zafar Ali (zali)" <[e-mail]>]

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 <[e-mail]> on behalf of "Joel M. Halpern" <[e-mail]>
Date: Friday, May 8, 2020 at 7:33 PM
To: Gyan Mishra <[e-mail]>
Cc: 6man WG <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]><mailto:[e-mail]%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
     <[e-mail]<mailto:[e-mail]>
     <mailto:[e-mail]><mailto:[e-mail]%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
     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
     --------------------------------------------------------------------

--

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>




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


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