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

[Gyan Mishra <[e-mail]>]

Will do.

Regards,

Gyan

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

> Gyan,
>
> Please move VPN related topics to BESS, original thread discusses here is
> EH Insertion.
>
> Wrt TI-LFA, MPLS Architecture RFC explicitly defines label stacking -
> https://tools.ietf.org/html/rfc3031#section-3.9
> Please note that draft-ietf-rtgwg-segment-routing-ti-lfa defines how to
> calculate a TI-LFA paths and uses notion of a SID, that is data plane
> agnostic. It doesn’t violate any existing standards.
>
> Cheers,
> Jeff
> On Dec 11, 2019, 3:27 PM -0800, Gyan Mishra <[e-mail]>,
> wrote:
>
> 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
>
>

-- 

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