Re: Header Insertion and TI-FA

[Gyan Mishra <[e-mail]>]

Andrew

I believe how we get around AH issue from a customer endpoint flow is that
the customer flow is tunneled, h.encap,  so sits in the payloadend to end
customer packet remains unaltered so their is no impact to end to end
customer flows if AH is used by any endpoint customer cuz. As far as the
outer header H.encap that happens on the SR source or TI-LFA merge point
the closer domain intra or inter domain SRv6 comes into play and if the
operator tries to use AH instead of ESP the operator that would be broken.
The operator would have to aware to not try to use AH and to use ESP
instead.

In SRH section 5 intra SR

https://tools.ietf.org/html/rfc8754

An operator of an SR domain may choose to delegate SRH addition to a
   host node within the SR domain and delegate validation of the
   contents of any SRH to a more trusted router or switch attached to
   the host.  Consider a top-of-rack switch T connected to host H via
   interface I.  H receives an SRH (SRH1) with a computed HMAC via some
   SDN method outside the scope of this document.  H classifies traffic
   it sources and adds SRH1 to traffic requiring a specific Service
   Level Agreement (SLA).  T is configured with an IACL on I requiring
   verification of the SRH for any packet destined to the SID block of
   the SR domain (S/s).  T checks and verifies that SRH1 is valid and
   contains an HMAC TLV; T then verifies the HMAC.

   An operator of the SR domain may choose to have all segments in the
   SR domain verify the HMAC.  This mechanism would verify that the SRH
   Segment List is not modified while traversing the SR domain.



Since the 6in6 encapsulation outer header that is prepended at the PLR node
is completely removed along with the EH SRH inserted by the merge point
along the FRR bypass path.

>From what I can tell TI-LFA if implemented per the PGM draft should be in
compliance with RFC 8200.

I believe I have a capture where EH SRH header is inserted - will try to
dig up.

There is a concept called BE L3VPN and with that configuration SRH is not
present.

I believe one of the benefits of SRv6 is being able to support on hardware
that is not SRv6 capable on any node even the Ingress and egress PEs and
just use the standard IPv6 data plane.

I believe the BE L3VPN feature is enabled default so no SRH is present.
This may vary from vendor to vendor.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-02

Kind regards

Gyan


On Mon, May 11, 2020 at 3:35 PM Andrew Alston <
[e-mail]> wrote:

> Correct me if I am wrong – but – removal is still in there – which
> violates exactly the same section of text and breaks things like the AH?
>
>
>
> Or are we saying – its ok to only half violate the text? 😊
>
>
>
> Andrew
>
>
>
>
>
> *From: *ipv6 <[e-mail]> on behalf of "Pablo Camarillo
> (pcamaril)" <pcamaril=[e-mail]>
> *Date: *Monday, 11 May 2020 at 20:13
> *To: *Gyan Mishra <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *RE: Header Insertion and TI-FA
>
>
>
> Gyan,
>
>
>
> SRH insertion is NOT part of draft-ietf-spring-srv6-network-programming-15.
>
> (SRH insertion is documented in
> draft-filsfils-spring-srv6-net-pgm-insertion-02 with a normative reference
> to draft-voyer-6man-extension-header-insertion-08).
>
>
>
> > Spring - Please provide section within PGM that has the verbiage of the
> 6in6 encapsulation
>
>
>
> This is already in the net-pgm draft (since rev 00). Please see
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5
> .
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From:* ipv6 <[e-mail]> *On Behalf Of *Gyan Mishra
> *Sent:* lunes, 11 de mayo de 2020 18:02
> *To:* Krzysztof Szarkowicz <[e-mail]>
> *Cc:* Ron Bonica <rbonica=[e-mail]>; 6man <
> [e-mail]>
> *Subject:* Re: Header Insertion and TI-FA
>
>
>
>
>
> Krzysztof
>
>
>
> So you agree with what I stated as the workaround.
>
>
>
> Please read through exactly what I stated as the complete workaround.
>
>
>
> If we are all in agreement with the prepend (6in6) encap) workaround can
> we have the PGM draft updated to reflect.
>
>
>
> All
>
>
>
> With regards to the 6MAN appeal,  the issues were PSP and this issue with
> TI-LFA from what I recall.
>
>
>
> Was their any other issue outside of these two mentioned in the appeal
> that we need to address and come up with a workaround?
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <
> [e-mail]> wrote:
>
> Hi Robert,
>
> If we have prepend, why bother with insertion at all? Prepend (6in6 encap)
> is much cleaner, IMHO.
>
> Regards,
> Krzysztof
>
> > On 2020 -May-11, at 16:38, Robert Raszuk <[e-mail]> wrote:
> >
> > Hi Ron,
> >
> > > normalizing header insertion for the special case where the PLR is a
> segment endpoint
> >
> > When an operator is serious about good data plane protection with TI-LFA
> all nodes in the network will be enabled for SR. The less overhead required
> for the protection the better. You may just not have a room for adding
> additional 40 bytes to each packet at each potential PLR without
> fragmentation.
> >
> > Regarding all of your other TI-LFA related questions - I am sure
> Krzysztof will be happy to answer them for you internally :)  After all
> this is what your public demo was all about ....
> >
> > Best,
> > Robert,
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]