Re: SRH insertion vs SRH insertion + encapsulation

[Robert Raszuk <[e-mail]>]

Hi Mark,

> If an SR device is using something else other than a packet's DA   to
> determine whether to process the packet beyond the IPv6 fixed header
> locally, or to forward it, then it isn't an IPv6 router or an IPv6
> host.

But the crux of the matter is that it is exactly the packet's DA which
determines that.

Of course on the way the packet transited the network the original DA was
placed on the stack and new DA got inserted into the original header to
enable new services on such packets. And the packet gets forwarded which
means it is still falling into router's definition.

Yes new complete header can be placed as well and no service degradation is
going to occur, but only efficiency will be worse. We got that one agreed
on already too.

With that let's keep in mind that LFA technology (leave alone BSIDs) where
unknown when IPv6 was defined. Moreover I am sure new technologies will be
proposed in the future to also benefit from mangling with original IPv6
application sender's complete v6 header while in transit.

So here 6man WG stands in the front of making a choice to either foster the
new services for IPv6 networks native or not.

And as last question to ask ... if you are doing say encapsulation on
ingress to your domain then another encapsulation for local failure
protection and sender of the original packet decided to include large (say
max 256 bytes) Hop-by-Hop Options extension header which should be by
definition examined by all devices on the path - do you every time copy
into new IPv6 encapsulation this type 0 EH or choosing not to copy this
therefor not allowing it to be inspected by all devices on the path ? I
just read 2473 and honestly I am not clear if it should be copied, may be
copied or may not be copied.

Thx,
R.

On Sat, Sep 7, 2019 at 3:47 PM Mark Smith <[e-mail]> wrote:

> On Sat, 7 Sep 2019 at 22:40, Robert Raszuk <[e-mail]> wrote:
> >
> > Hi,
> >
> > Mark, Fernando, Tom - many thx indeed.
> >
> > For me word "insertion" was not a reserved word. I think I now start to
> understand the rationale on how and why you reacted like you did.
> Especially if you say that "insertion" by definition is/must be anonymous.
> >
>
> It's also the splitting apart of existing packets. That is not an
> standard IPv6 operation. Only encapsulation/de-encapsulation is.
>
> Splitting packets apart is far more complicated than encapsulation
> particularly when there may be existing EHs in the packet, and more
> complicated than identifying packets to be de-encapsulated and
> processed just by their Destination Address, which is the standard
> IPv6 (and IPv4) way to identify packets that are to be processed by
> the local node other than using forwarding.
>
> Note the RFC 8200 definition of a router and a host, which are
> functional definitions (although we all would usually think of them as
> devices):
>
>   router       a node that forwards IPv6 packets not explicitly
>                 addressed to itself.  (See Note below.)
>
>    host         any node that is not a router.  (See Note below.)
>
> (For completeness, part of the Note
>
> "Note: it is possible for a device with multiple interfaces to be
>    configured to forward non-self-destined packets arriving from some
>    set (fewer than all) of its interfaces and to discard non-self-
>    destined packets arriving from its other interfaces.")
>
> If an SR device is using something else other than a packet's DA to
> determine whether to process the packet beyond the IPv6 fixed header
> locally, or to forward it, then it isn't an IPv6 router or an IPv6
> host. It's undefined, and quite probably a middle box. (It may
> physically look like a router, but it's functions that matter in the
> context of protocols.)
>
> Regards,
> Mark.
>
> > So if this is what drives all of the opposition to place SRH into a IPv6
> header without encapsulation then I think there easy ways to fix it.
> >
> > I will then talk to some other others about options they are willing to
> incorporate into relevant documents.
> >
> > Many thx,
> > R.
> >
> >
> >
> >> Yes, however I don't consider there to be any "insertion" happening at
> >> all in that scenario, and I don't think anybody else in the IPv6 6man
> >> WG would either.
> >>
> >> "EH insertion" is splitting apart an existing IPv6 packet after the
> >> IPv6 header and before the payload, inserting the EH, creating or
> >> modifying an existing EH chain, leaving the packet's original source
> >> and destination address as they were.
> >>
> >> This is why EH insertion is anonymous - the source address in the
> >> packet is not the identity of the device that inserted the EH. The EH
> >> insertion being anonymous is what causes all the problems - breaking
> >> PMTUD, IPsec, ICMP in general, causing problems if the EH isn't
> >> removed when it should be, and making troubleshooting much harder.
> >>
> >> Encapsulation in another new IPv6 packet creates the option to add,
> >> not insert, new supplementary information via EHs.
> >>
> >> From RFC 2473, "Generic Packet Tunneling in IPv6 Specification"
> >>
> >>                             +----------------------------------//-----+
> >>                             | Original |                              |
> >>                             |          |   Original Packet Payload    |
> >>                             | Header   |                              |
> >>                             +----------------------------------//-----+
> >>                              <            Original Packet            >
> >>                                               |
> >>                                               v
> >>        <Tunnel IPv6 Headers> <       Original Packet                 >
> >>
> >>       +---------+ - - - - - +-------------------------//--------------+
> >>       | IPv6    | IPv6      |                                         |
> >>       |         | Extension |        Original Packet                  |
> >>       | Header  | Headers   |                                         |
> >>       +---------+ - - - - - +-------------------------//--------------+
> >>        <                          Tunnel IPv6 Packet                 >
> >>
> >>                        Fig.3 Encapsulating a Packet
> >>
> >> SRH, OAM etc. EHs that are added to the original packet would go in
> >> the "IPv6 Extension Headers" area shown in the lower packet of that
> >> diagram, after the new outer tunnel header.
> >>
> >> Encapsulation/Decapsulation is an addition/subtraction operation of
> >> new, non-original sender information. It preserves the original packet
> >> as it was when it was originally sent.
> >>
> >> It provides a new source address field to identify the device that
> >> performed the encapsulation and that added the supplementary
> >> information via the added EHs.
> >>
> >> It provides a new destination address field to unambiguously identify
> >> which device the added EH information is intended to be processed by.
> >> There is no need for these EH processing devices to be looking beyond
> >> the IPv6 fixed header to determine if there are any EHs for them to
> >> process - if it is for them, it is a simple and IPv6 standard packet
> >> DA to device DA match operation which answers that question. If it is
> >> not for them, the forward it via their FIB.
> >>
> >> Yes encapsulation adds overhead, however that overhead makes
> >> everything compliant with existing decades old methods, models, tools,
> >> operations and troubleshooting techniques.
> >>
> >> Regards,
> >> Mark.
> >>
> >>
> >> >and if any document would like to take that path fwd there is no
> objections from 6man in regards to violation or not of any former 6man or
> IPv6 consensus.
> >> >
> >> > - - -
> >> >
> >> > So on the very topic let me summarize the observations made in
> various emails:
> >> >
> >> > #1
> >> >
> >> > The draft in question doesn't comment on the most basic question: why
> do
> >> > you want to do EH-insertion as opposed to encap/decap into a new
> packet?
> >> >
> >> > I asked this question a number of times, and nobody answered.. Rumor
> on
> >> > the corridors had it that it had to do with one specific vendors
> having
> >> > issues (of some sort) with implementing this with doing encap/decap.
> --
> >> >
> >> > Looks to me like FUD at best - just suffice to read (with
> understanding)
> >> >
> >> > draft-matsushima-spring-srv6-deployment-status-01
> >> >
> >> > - - -
> >> >
> >> > #2
> >> >
> >> > EH insertion will increase the MTU of the packet.
> >> >
> >> > It sure will but as already stated this is done within a given domain
> so someone who is doing insertion better makes sure it is not causing
> packet drops. Otherwise his customers may be pretty unhappy.
> >> >
> >> > If you do EH insertion + encapsulation to my basic math skills it
> looks like you are creating even bigger packet. So you are more likely to
> face MTU bottleneck issues.
> >> >
> >> > - - -
> >> >
> >> > # 3
> >> >
> >> > I also have a nit about that draft. The very first line of the
> >> > abstract is "The network operator and vendor community has clearly
> >> > indicated that IPv6 header insertion is useful and required."
> >> >
> >> > I agree - such statements should not be in the IETF standards track
> document.  Such document should be judged on its technical merits not on a
> basis of crusade.
> >> >
> >> > - - -
> >> >
> >> > # 4
> >> >
> >> > The draft doesn't say why insertion is considered necessary. There is
> no justification presented.
> >> >
> >> > Well I can understand why one may say so if he does not follow years
> of FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique
> of provide fast connectivity restoration is based on the fact of local
> repair with local bypass of the broken fragment of the network in a loop
> free manner. That requires some form of controlled packet steering around
> the failure.
> >> >
> >> > There are many techniques to achieve such steering SR is an elegant
> one for this specific application. The less bits you add to the packet the
> better. Usually you are fine with just one SID or in number of topologies
> you actually do not need any SID so just placing original dst address into
> SRH and applying new dst address may be all what is required.
> >> >
> >> > I understand that for some FRR techniques do not matter .. some may
> use completely different end to end techniques (I like those btw :) but for
> some it has been a necessity to provide best service to their customers.
> >> >
> >> > - - -
> >> >
> >> > #5
> >> >
> >> > There is no statement that says, "When using IPv6 tunnelling with 128
> bit SIDs, the per packet overhead can become too high."
> >> >
> >> > The proposal to use insertion without encap saves you up front 320
> bits. I think the less bits you put in *each* packet the better. As
> described in #4 - in vast majority of TI-LFA you only need one external
> anchor to safely bypass the failure so in fact no need for any SIDs as the
> original dst will be either in inner header or in inserted SRH. So your
> repair efficiency as far as extra packet size already  is more then 2 times
> less when doing SRH insertion vs SRH or CRH insertion with encapsulation.
> >> >
> >> > - - -
> >> >
> >> > # 6
> >> >
> >> > EH insertion is entirely anonymous. If something breaks, you have no
> >> > idea of which device inserted the EH.
> >> >
> >> > If inserted SRH contains the routable identified of the network
> element which inserted the header does this address this point ?
> >> >
> >> >
> >> > - - -
> >> >
> >> > # 7
> >> >
> >> > EH insertion sounds to me like it is breaking a fundamental principle
> >> > of trying to avoid sending something unexpected and that the receiver
> >> > will be confused by.
> >> >
> >> > If EH is removed within the domain it has been inserted end receiver
> never sees it.
> >> >
> >> > = = =
> >> >
> >> > I think I see why in general you all consider that EH insertion alone
> would be a bad thing. But I think here we are not talking about any
> insertion to be allowed. We are discussing a fixed and well defined
> extension which could be made sure that all valid hooks to address
> potential concerns are embedded in its encoding yet still maintaining
> forwarding efficiency.
> >> >
> >> >
> >> > I think now it is up to 6man WG and chairs how they choose to
> continue this dialogue.
> >> >
> >> > Many thx,
> >> > R.
> >> >
> >> >
> >> >
> >> > --------------------------------------------------------------------
> >> > IETF IPv6 working group mailing list
> >> > [e-mail]
> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>