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

[Gyan Mishra <[e-mail]>]

Stephane

My confusion on best effort L3 VPN and what that means.

I thought that meant the entire underlay PE & P is not SRv6 aware and that
is not the case. I was struggling to understand how that could possibly
work which did not make sense.  So the verbiage states the Best effort L3
VPN which is ingress and egress PE SRv6 enabled but does not mention step 3
which is really now migration step 2 where all P nodes are SRv6 aware for
TI-LFA.  Even though the P nodes are “BGP free” core I think it’s a good
idea to mention that scenario to bring it all together as far as the BGP
overlay services operation.

On Wed, Dec 11, 2019 at 6:14 PM Gyan Mishra <[e-mail]> wrote:

> 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
>
> --

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