Re: Extension Header Insertion

Hi Adrian

When the 2nd SRH is added at the PLR node for TI-LFA how does the PLR node
know that it should now proceed with processing the 2nd SRH added and not
continue using the 1st SRH.  For TI-LFA the backup path around the node
that failed would be referenced using the 2nd SRH which is associated with
the fast reroute operational during a node failure for path protection.
The 1st SRH would be used for nomal conditions non failure scenario.  So
how does the SRv6 capable node know which SRH to use when two or mode are
present for each of the distinct scenarios.

Which draft is that documented in for my reference.

Also I was wondering it seems their is a scenario during migration to SRv6
where you don’t have to have all your routers be SRV6 capable day 1 and all
that is required is all nodes in the SRv6 domain have IPv6 routing enabled
for the IPv6 data plane to be present.  From a migration perspective Best
Effort L3 VPN it sound like would be the first step and basically none of
the nodes are SRv6 enabled and no SRH is present however all L3 VPN
services sit as overlay BGP services encapsulated in IPv6.  The next step
would be to SRv6 enable all PEs so that the SRH eh can be added for source
routing the customer traffic.  During that 2nd step only a single SRH
exists and that is added by the SR domain ingress PE source node to the FEC
destination.  A 3rd and final step would be to upgrade all nodes to be SRv6
capable at which time any node could be a PLR node for TI-LFA fast reroute
and that’s where the 2nd SRH eh header is added.  In end state
hypothetically you can many nodes in the domain in a failure state
initiating FRR at the PLR node and using the backup path.  So in practice
practical application you would not have the additional SRH EH added pre
built also thinking of this from a path perspective.  With TI-LFA the PLR
node builds a tunnel the PQ node endpoint.  I am referencing terminology
used my Remote LFA tunneling when an additional label is added at the PLR
junction point to to the PQ node tunnel termination endpoint where the
label added on PLR node is removed by the PQ node.  I believe SRv6 TI-LFA
works similarly to MPLS   ldp remote LFA where an MPLS label as added
tunneling to PQ node.

So with SRv6 TI-LFA is an encapsulation added with the SRH header similar
to MPLS ldp remote LFA.  If so then that is the case then the added SRH EH
is part the new outer layer 6in6 encapsulation and now its obvious it will
use the SRH added as part of the encapsulation and then upon reaching the
PQ tunnel endpoint node competing the fast reroute the outer header added
at the PLR node is then popped.  So now you are left with the single
original SRH that was inserted at the SRv6 source PE node.  So since the
path is linear drawing a straight line across the SRv6 domain whenever a
failure occurs the TI-LFA encap and SRH would be added at the PLR node and
subsequently removed at the PQ node.

So then you would from what I can tell based on the packet walk in my head
you would at an given point in time never have more then two SRH eh
inserted and each SRH would be part of a different outer header.  So in
theory you would never have to SRH headers with the same outer header as
Ron depicted.

Please let me know if I am way off on my thinking.

Kind regards,

Gyan

On Mon, Dec 9, 2019 at 10:33 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Darren,
>
>
>
> Thanks for your considered and friendly reply.
>
>
>
> Thanks for the additional pointer to 8200. I (of course) was not involved
> in the production of that document, but I read it as doing two things:
>
>    1. Setting the high-level behaviour for general processing.
>    This is the text you quote.
>    2. Giving detailed rules about specific EHs for order and presence.
>    The text I quoted.
>
>
>
> So I would be guided by 8200 to not expect to see a second routing header
> (e.g., SRH).
>
>
>
> Of course, I might implement to see the second one and treat it as an
> unknown EH. That would be good self-protection code.
>
>
>
> Now, I said “Thus we may assume that the proponents of Extension Header
> insertion do think that it is acceptable to insert a second routing header
> into a packet that already has one.” And you said “I do not agree with
> your assumptions”. So can I take it that you do not think it is acceptable
> to insert a second SRH into a packet that already has one?
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Darren Dukes (ddukes) <ddukes@cisco.com>
> *Sent:* 09 December 2019 13:31
> *To:* adrian@olddog.co.uk; 'Ron Bonica' <rbonica=
> 40juniper.net@dmarc.ietf.org>; '6man' <6man@ietf.org>
> *Subject:* Re: Extension Header Insertion
>
>
>
> Hi Adrian. You failed to quote the section of rfc 8200 where it says “IPv6
> nodes must accept and attempt to process extension headers in
>
>    any order and occurring any number of times in the same packet,”
>
>
>
> I do not agree with your assumptions nor the attempt to imply something
> about the Other drafts.
>
>
>
> Darren.
>
>
> ------------------------------
>
> *From:* ipv6 <ipv6-bounces@ietf.org> on behalf of Adrian Farrel <
> adrian@olddog.co.uk>
> *Sent:* Monday, December 9, 2019 4:34 AM
> *To:* 'Ron Bonica'; '6man'
> *Subject:* RE: Extension Header Insertion
>
>
>
> Hi Ron,
>
>
>
> I think we can jump to a quick answer on this because
> draft-ietf-spring-srv6-network-programming-05 says:
>
>
>
>    We assume that the SRH may
>
>    be present multiple times inside each packet.
>
>
>
> Thus we may assume that the proponents of Extension Header insertion do
> think that it is acceptable to insert a second routing header into a packet
> that already has one.
>
>
>
> And 8200 is clear when it says:
>
>    Each extension header should occur at most once, except for the
>
>    Destination Options header, which should occur at most twice (once
>
>    before a Routing header and once before the upper-layer header).
>
>
>
> So draft-ietf-spring-srv6-network-programming-05 includes a false
> assumption which need to be either removed or secured through an update to
> 8200.
>
>
>
> Ideally, I suppose, draft-ietf-6man-segment-routing-header would have
> contained the clarification that the SRH could be present multiple times
> (updating 8200 as it went).
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Ron Bonica
> *Sent:* 09 December 2019 03:04
> *To:* 6man <6man@ietf.org>
> *Subject:* Extension Header Insertion
>
>
>
> Folks,
>
>
>
> This question is posed primarily to the proponents of Extension Header
> insertion.
>
>
>
> Do you think that it is acceptable to insert a second routing header into
> a packet that already has one, so the resulting packet looks like the
> following:
>
>
>
>    - IPv6 header
>    - SRH
>    - SRH
>    - Upper-layer header
>
>
>
> Would this be common in TI-LFA?
>
>
>
>                                                                       Ron
>
>
>
>
>
> Juniper Business Use Only
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> 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: 301 502-1347

Email: gyan.s.mishra@verizon.com

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