Re: What if? [was Re: Extension Header Insertion]

[Gyan Mishra <[e-mail]>]

Thanks Jeff!!

+ Stephane

I see the TI-LFA draft expired in the data tracker.

Thank you for updating.  I will send the comments to the rtgwg.

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/


I added Stephane as the co chair for bess WG.

Stephane

We recently had a WGLC on this draft which is expired.  This is a critical
draft as goes into details of BGP overlay services on SRv6.  In the context
of eh insertion in flight violation on the SRv6 source node, this draft
shows the BGP overlay services are 6in6 encapsulated on the SRv6 source
node depicting pictorially that any flow ingress to SRv6 source node is
from an external edge CE and NLRI is propagated into multi protocol BGP.

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

Below mentions “best effort L3 VPN” which is when the underlay has an IPv6
data plan step 1 in migration to SRv6 but does not mention step 2 where PEs
are upgraded for SRv6 support and step 3 where all P nodes as well are
upgraded to support TI-LFA.  Was that intentional left out and if not can
that verbiage  be updated in the next revision.

Bottom of page 3  excerpt - To provide SRv6 service with best-effort
connectivity, the egress PE signals an SRv6 Service SID with the BGP
overlay service route. The ingress PE encapsulates the payload in an outer
IPv6 header where the destination address is the SRv6 Service SID provided
by the egress PE. The underlay between the PEs only need to support plain
IPv6 forwarding [RFC8200].
   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service

route with a Color extended community
[I-D.ietf-idr-segment-routing-te-policy]. The ingress PE encapsulates the
payload packet in an outer IPv6 header with an SRH that contains the
segment list of SR policy associated with the related SLA followed by the
SRv6 Service SID associated with the route. The underlay nodes whose SRv6
SID’s are part of the SRH MUST support SRv6 data plane.
BGP is used to advertise the reachability of prefixes of a particular
service from an egress PE to ingress PE nodes.

Stephan

On Wed, Dec 11, 2019 at 12:11 PM Jeff Tantsura <[e-mail]>
wrote:

> Stewart,
>
> /rtgwg chair hat on
> Please send your ti-lfa comments to the rtgwg list, Stephane (editor) is
> working on the updates.
>
> Regards,
> Jeff
>
> On Dec 11, 2019, at 03:50, Stewart Bryant <[e-mail]>
> wrote:
>
> 
>
>
>
> On 11 Dec 2019, at 05:51, Gyan Mishra <[e-mail]> wrote:
>
> Hi Warren,
>
> Just a thought.
>
> There have been other game changer technologies that have come up in the
> past that really require a lot of collaboration between all WG silo’s
> namely mpls for starters and now SR which has I am guessing millions poured
> into by vendors across the globe to get on the band wagon which will be the
> eventual replacement of mpls.
>
> Not to derail my thoughts — SR for example just as with MPLS involved many
> routing and internet area WGs such as rtgwg, lsr, Bess, teas to name a
> few.  There is a lot of complexity in development and maintaining IETF
> standards when there are so many very complex inter dependencies between
> WGs for these types of industry evolution type protocols that pave the way
> for the future.
>
> To that point the topic of TI-LFA which we have talked about in many
> threads.  This draft is owned by rtgwg. I don’t think the authors of this
> draft being a dependency WG of the WG owner of the main protocol being
> developed “spring” had knowledge that they were in violation of RFC 8200.
> I think that is part of the root problem with the process flow in
> development of a very complex protocol that spans almost every IETF WG.
>
> TI-LFA draft:
> https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf
>
> Bottom of page 3-
> Thanks to SR, TI-LFA does not require the establishment of TLDP sessions
> with remote nodes in order to take advantage of the applicability of remote
> LFAs (RLFA) [RFC7490][RFC7916] or remote LFAs with directed forwarding
> (DLFA)[RFC5714].
>
>
> The TI-LFA draft is data-plane agnostic.
>
> How the draft maps to the dataplane is up to the dataplane designers.
>
> With an MPLS dataplane it all works and conforms to the MPLS architecture.
>
> It is up to the IP dataplane designers to ensure that it conforms to the
> IP dataplane architecture.
>
>
>
>
> I mentioned in on of the threads that MPLS ldp RLFA (remote LFA) requires
> an MPLS label to be added to ldp tunnel to PQ space end node in a  circle
> topology case where PLR node junction physical bypass LFA  node does not
> exist.  Since the backup path programmed is a post convergence path with
> stateless nodes with SRv6, 6in6 encapsulation at the PLR node  is not
> technically necessary.
>
> If the rtgwg new they were in violation of RFC 8200 they would have gone
> the same path as ldp RLFA and added in the encapsulation into the draft.
>
>
> As far as I can see the document you cite says nothing about IPv6 and thus
> cannot violate RFC8200, or have I missed something in the text?
>
> You mention the congruence between the repair path and the post
> convergence path. As far as I can see this is loop mitigation in the down
> case (it says nothing about loop mitigation in the up case which is also an
> important problem). Anyway, I stress that I have not yet seen a formal
> proof that it is unconditional loop avoiding as post convergence the
> packets may not go via the PLR and hence may not follow the TI-LFA path. I
> have asked before and have not yet seen such a proof (I apologies if I have
> missed it) and look forward to reading it.
>
> Best regards
>
> Stewart
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant