Subject: Extension Header Insertion

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 03:04:27 +0000

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Dec 2019 09:33:48 -0000

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 <[email-masked]> On Behalf Of Ron Bonica
Sent: 09 December 2019 03:04
To: 6man <[email-masked]>
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

                                                                      Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 9 Dec 2019 13:31:28 +0000

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 <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
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:

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.

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

Folks,

  *   IPv6 header
  *   SRH
  *   SRH
  *   Upper-layer header

                                                                      Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 9 Dec 2019 13:32:44 +0000

Hi Ron.

Yes, this is possible with SRH insertion.

Darren

________________________________
From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Sunday, December 8, 2019 10:04 PM
To: 6man
Subject: Extension Header Insertion

Folks,

  *   IPv6 header
  *   SRH
  *   SRH
  *   Upper-layer header

                                                                      Ron

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Dec 2019 07:08:15 -0800

>    before a Routing header and once before the upper-layer header).
Adrian,

It's probably arguable if that would be a SHOULD or a MUST requirement
in normative language. In either case, the expectation is that
different types of extension headers only appear once. It is
conceivable that some receiving implementations enforce this
assumption so that in the presence of multiple occurrences things
could fail (i.e. be conservative in what you send).

Note that encapsulation with EH instead of Eh insertion would avoid
multiple occurrences of EH within the same IP packet thereby
maintaining the expectation in RFC8200.

Tom

> IPv6 header
> SRH
> SRH
> Upper-layer header
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Dec 2019 15:33:00 -0000

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) <[email-masked]> 
Sent: 09 December 2019 13:31
To: [email-masked]; 'Ron Bonica'
<rbonica=[email-masked]>; '6man' <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > on behalf
of Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Sent: Monday, December 9, 2019 4:34 AM
To: 'Ron Bonica'; '6man'
Subject: RE: Extension Header Insertion 

Hi Ron,

Cheers,

Adrian

From: ipv6 <[email-masked] <mailto:[email-masked]> > On Behalf
Of Ron Bonica
Sent: 09 December 2019 03:04
To: 6man <[email-masked] <mailto:[email-masked]> >
Subject: Extension Header Insertion 

Folks,

*	IPv6 header
*	SRH
*	SRH
*	Upper-layer header

                                                                      Ron

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Dec 2019 11:31:06 -0500

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 <[email-masked]> wrote:

> 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:
>
> Now, I said “Thus we may assume that the proponents of Extension 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) <[email-masked]>
> *Sent:* 09 December 2019 13:31
> *To:* [email-masked]; 'Ron Bonica' <rbonica=
> [email-masked]>; '6man' <[email-masked]>
> *Subject:* Re: Extension Header Insertion
>
>
>
> Hi Adrian. You failed to quote the section of rfc 8200 where it says “IPv6
> ------------------------------
>
> *From:* ipv6 <[email-masked]> on behalf of Adrian Farrel <
> [email-masked]>
> *Sent:* Monday, December 9, 2019 4:34 AM
> *To:* 'Ron Bonica'; '6man'
> *Subject:* RE: Extension Header Insertion
>
>
>
> Hi Ron,
>
>
>
> 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.
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Ron Bonica
> *Sent:* 09 December 2019 03:04
> *To:* 6man <[email-masked]>
> *Subject:* Extension Header Insertion
>
>
>
> Folks,
>
>
>
> 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
>
>
>
-- 

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: [email-masked]

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 22:35:35 +0000

Darren,

This email adds context:

https://mailarchive.ietf.org/arch/msg/spring/wxnefX2EyqETjLKY1BGGYQMN2Qk

                                                             Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Monday, December 9, 2019 8:31 AM
To: [email-masked]; Ron Bonica <[email-masked]>; '6man' <[email-masked]>
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,"

Darren.

________________________________
From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 9, 2019 4:34 AM
To: 'Ron Bonica'; '6man'
Subject: RE: Extension Header Insertion

Hi Ron,

Cheers,
Adrian

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ron Bonica
Sent: 09 December 2019 03:04
To: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Extension Header Insertion

Folks,

  *   IPv6 header
  *   SRH
  *   SRH
  *   Upper-layer header

                                                                      Ron

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2019 14:02:08 +1300

>    before a Routing header and once before the upper-layer header).

That's "should", which in a non-RFC2119 document like RFC 8200, means "should".
It's not "must". So while I would prefer that the relevant SRH document justifies
the exception, there isn't a breach of a mandatory requirement.
  
> Ideally, I suppose, draft-ietf-6man-segment-routing-header would have contained the clarification that the SRH could be present multiple times 

Yes

> (updating 8200 as it went).

Unnecessary, IMHO.

    Brian

> 
>  
> 
> Cheers,
> 
> Adrian
> 
>  
> 
> *From:*ipv6 <[email-masked]> *On Behalf Of *Ron Bonica

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2019 14:21:06 +1300

So, let's assume that two consecutive SRH headers are allowed in the same packet.

So the first one (an example from draft-ietf-6man-segment-routing-header-26) is:

       Segments Left=2
       Last Entry=2
       Flags=0
       Tag=0
       Segment List[0]=S3
       Segment List[1]=S2
       Segment List[2]=S1

and the second one is

       Segments Left=1
       Last Entry=1
       Flags=0
       Tag=0
       Segment List[0]=S4
       Segment List[1]=S5

I made that up and it's obviously nonsense, but if this is allowed why aren't the rules for processing conflicting SRHs described in draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the RFC Editor queue to be fixed?

Regards
   Brian Carpenter

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Dec 2019 00:28:04 -0500

Brian

I would like to put this into proper context for SRv6 and how it would be
deployed in a real world scenario so we can fully connect all the dots of
this puzzle.

So with SRv6 the 1st SRH eh insertion would never be in flight eh insertion
in the middle of the network.

Providing some context below.

The topology is identical to a typical service provider MPLS core where you
have a PE-CE link to customers.  So in the MPLS scenario the Ingress PE
would add L3 VPN MBGP bottom of stack label for the customer VRF PE-CE
attachment circuit.

With SRv6 the L3 VPN MBGP is encapsulated in IPv6 and sits in the overlay
as the inner header payload since now with SRv6 we have an IPv6 data plane
as our underlay 6in6 outer header instead of MPLS ldp topmost label.
Essentially we are swapping MPLS ldp topmost label for SRv6 IPv6 data plane
underlay with all BGP services overlay remaining as-is intact AFI/SAFI
riding on top of SRv6 sitting in the 6in6 payload.

The SRv6 source node ingress PE of the SR domain would now encapsulate the
SRv6 L3 services TLV and at the same time inserts SRH header routing type 4
for the hop by hop traffic engineering of the flow through the controlled
SRv6 operators domain.

So from the big picture standpoint the 1st SRH eh insertion is most
definitely not in the middle of the network and not in flight eh insertion
since the BGP services TLV originating from the external CE edge is
tunneled over the SRv6 IPv6 data plane controlled operator domain.

BESS WG draft depicts the L3 vpn services TLV that is 6in6 tunneled sits in
the overlay.

https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02

2 <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-2>.
SRv6 Services TLVs

   This document extends the BGP Prefix-SID attribute
   [I-D.ietf-idr-bgp-prefix-sid
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-idr-bgp-prefix-sid>]
to carry SRv6 SIDs and associated
   information.

   The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
   SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
   services.

   o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
      SRv6 based L3 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label when received with a Layer
      3 service route.  Some behaviors which MAY be encoded, but not
      limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.

   o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
      SRv6 based L2 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label1 for EVPN Route-Types as
      defined in[RFC7432].  Some behaviors which MAY be encoded, but not
      limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc.

   When an egress PE is enabled for BGP Services over SRv6 data-plane,
   it MUST signal one or more SRv6 Service SIDs enclosed in SRv6 Service
   TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
   defined in [RFC4760
<https://tools.ietf.org/html/rfc4760>][RFC4659][RFC5549
<https://tools.ietf.org/html/rfc5549>][RFC7432][RFC4364
<https://tools.ietf.org/html/rfc4364>] where
   applicable as described in section 3
<https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-3>
and 4.

   The 2nd SRH EH insertion with TI-LFA occurs at the PLR point of local

Repair node to the loop free PQ node.

So this addition SRH header is only inserted and   removed during a
failure fast reroute.  I believe  but not sure if TI-LFA behaves the
same as MPLS ldp

Remote LFA where a MPLS label is added at the PLR

Node and tunneled to the PQ node.  I am still      researching that one.

With SRv6 the use cases are for wherever you use mpls public internet or
private or enterprise scenario so you would always have the same SR source
PE encapsulation of the edge CE L3 services TLV and so in any of those use
cases would not be a middle of the network in flight EH insertion which is
a violation of RFC 8200.

Gyan

On Mon, Dec 9, 2019 at 8:21 PM Brian E Carpenter <
[email-masked]> wrote:

> So the first one (an example from
> draft-ietf-6man-segment-routing-header-26) is:
>
>        Segments Left=2
>        Last Entry=2
>        Flags=0
>        Tag=0
>        Segment List[0]=S3
>        Segment List[1]=S2
>        Segment List[2]=S1
>
> and the second one is
>
>        Segments Left=1
>        Last Entry=1
>        Flags=0
>        Tag=0
>        Segment List[0]=S4
>        Segment List[1]=S5
>
> I made that up and it's obviously nonsense, but if this is allowed why
> aren't the rules for processing conflicting SRHs described in
> draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the
> RFC Editor queue to be fixed?
>
> Regards
>    Brian Carpenter
>
> >> 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
> >>
> >>
> >>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Dec 2019 00:56:06 -0500

Confirming below that SRv6 TI-LFA does not require Remote LFA or DLFA so
their is no additional 6in6 encapsulation done as with MPLS ldp remote LFA
where a MPLS label is added to tunnel the flow to the PQ node.

https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf

So with SRv6 TI-LFA we would definitely have in flight SRH EH insertion
anywhere in the network where their is a failure and fast reroute pre
programmed backup SRH path exists.

IPv6 header
  * SRH -SRv6 source node
  * SRH -TI-LFA PLR node
IPv6 header -L3 services TLV
  * Upper-layer header

Gyan

On Tue, Dec 10, 2019 at 12:28 AM Gyan Mishra <[email-masked]> wrote:

> So with SRv6 the 1st SRH eh insertion would never be in flight eh
> insertion in the middle of the network.
>
> The topology is identical to a typical service provider MPLS core where
> you have a PE-CE link to customers.  So in the MPLS scenario the Ingress PE
> BESS WG draft depicts the L3 vpn services TLV that is 6in6 tunneled sits
> in the overlay.
>
> 2
> <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-2>.
> SRv6 Services TLVs
>
>    [I-D.ietf-idr-bgp-prefix-sid <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#ref-I-D.ietf-idr-bgp-prefix-sid>] to carry SRv6 SIDs and associated
>    information.
>
>    defined in [RFC4760 <https://tools.ietf.org/html/rfc4760>][RFC4659][RFC5549 <https://tools.ietf.org/html/rfc5549>][RFC7432][RFC4364 <https://tools.ietf.org/html/rfc4364>] where
>    applicable as described in section 3 <https://tools.ietf.org/html/draft-dawra-bess-srv6-services-02#section-3> and 4.
>
> So this addition SRH header is only inserted and   removed during a failure fast reroute.  I believe  but not sure if TI-LFA behaves the same as MPLS ldp
>
>> >> 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.
>> >>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 03:21:14 -0500

Hello, Gyan,

Is it me, or somehow when asked a simple question this results in
complexity explosion -- not unusually diverting the attention elsewhere
(where intentionally or unintentionally)?

Let's make things simple:

1) The SRH draft draft-ietf-6man-segment-routing-header talks about
encapsulating an incoming packet into a new header, that incorporates a
SRH. Of course, this is encapsulation/tunneling, so this does not result
in header insertion.

2) Things like TI-LFA have been implemented by inserting a new SRH n
flight, leasing to the situation described by Brian (and  going against
the recommendation in RFC8200)

3) Penultimate Segment Popping results in the SRH being removed
in-flight, violating RFC8200.

Going back to #2, the scenario raised by Brian: from a semantical point
of view, a packet containing two SRH does not make any sense.

Thanks,
Fernando

On 10/12/19 00:28, Gyan Mishra wrote:
> 
> Brian 
> 
> 
> I would like to put this into proper context for SRv6 and how it would
> be deployed in a real world scenario so we can fully connect all the
> dots of this puzzle.
> 
> you have a PE-CE link to customers.  So in the MPLS scenario the Ingress
> PE would add L3 VPN MBGP bottom of stack label for the customer VRF
> PE-CE attachment circuit.
> 
> With SRv6 the L3 VPN MBGP is encapsulated in IPv6 and sits in the
> overlay as the inner header payload since now with SRv6 we have an IPv6
> data plane as our underlay 6in6 outer header instead of MPLS ldp topmost
> label.  Essentially we are swapping MPLS ldp topmost label for SRv6 IPv6
> data plane underlay with all BGP services overlay remaining as-is intact
> AFI/SAFI riding on top of SRv6 sitting in the 6in6 payload.
> 
> The SRv6 source node ingress PE of the SR domain would now encapsulate
> the SRv6 L3 services TLV and at the same time inserts SRH header routing
> type 4 for the hop by hop traffic engineering of the flow through the
> controlled SRv6 operators domain.
> 
> definitely not in the middle of the network and not in flight eh
> insertion since the BGP services TLV originating from the external CE
> edge is tunneled over the SRv6 IPv6 data plane controlled operator domain.
> 
> private or enterprise scenario so you would always have the same SR
> source PE encapsulation of the edge CE L3 services TLV and so in any of
> those use cases would not be a middle of the network in flight EH
> insertion which is a violation of RFC 8200.
> 
> Gyan
> 
> On Mon, Dec 9, 2019 at 8:21 PM Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I made that up and it's obviously nonsense, but if this is allowed
>     why aren't the rules for processing conflicting SRHs described in
>     draft-ietf-6man-segment-routing-header-26? Do we need to recall it
>     from the RFC Editor queue to be fixed?
> 
>     Regards
>        Brian Carpenter
> 
>     >> 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.
>     >>
>     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
>     >
>     > Yes
>     >
>     >> *From:*ipv6 <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Ron Bonica
>     >> *To:* 6man <[email-masked] <mailto:[email-masked]>>
>     >> 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
>     >>
>     >>  
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> Email: [email-masked] <mailto:[email-masked]>
> 
> <http://www.linkedin.com/in/networking-technologies-consultant>
> 
> 
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 03:39:16 -0500

Hi, Brian,

> So, let's assume that two consecutive SRH headers are allowed in the same packet.

Part of the problem with all these discussions is that folks seem to
assume that there is no rationale for the existing rules, and they
insist on changing them without providing any analysis/rationale.

RFC8200 contains what should be considered a recommendation (at the very
least) against multiple routing headers.

A RH is meant to convey some sort of information about the path that a
packet can traverse. So two SRHs would mean that the same packet should
follow two different paths, at the same time. That doesn't seem to be
much sense to me.

> I made that up and it's obviously nonsense, but if this is allowed why aren't the rules for processing conflicting SRHs described in draft-ietf-6man-segment-routing-header-26? Do we need to recall…

It is clearly recommended against.

However, the very draft-voyer-6man-extension-header-insertion doesn't
even provide a rationale for EH insertion in the first place, let alone
for this specific case that you (reasonably) raise.

Unfortunately, when operating in a mode where analysis is discoraged,
and "why?" questions are dismissed, I'm not sure there is any other
possible alternative outcome than this -- documents with lots of
unspecified stuff, violating specs at will, and designs try to cover up
what seem to be sub-optimal design choices (like using 128-bit labels
for what are expected/supposed to be limited domains) by screwing up the
architecture to save bytes that were wasted elsewhere.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 03:48:34 -0500

On 10/12/19 00:56, Gyan Mishra wrote:
> their is no additional 6in6 encapsulation done as with MPLS ldp remote
> LFA where a MPLS label is added to tunnel the flow to the PQ node.
> 

Summarized for us mere-mortals: RFC8200 is being violated here.

{INT, RTG} ADs: it would seem you also need to add
draft-ietf-rtgwg-segment-routing-ti-lfa to the list of documents that
are violating RFC8200.

It would seem to me that something is missing in the process of how
these documents are being produced.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Dec 2019 11:29:54 +0000

> On 9 Dec 2019, at 03:04, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>  

Given that the advantage of SRv6 is always quoted as being that the whole path is available to the receiver for audit purposes, shouldn’t the TI-LFA path be inserted in the existing SRH (if present) so that the packet can be inspected on reception and adherence to policy be verified for the whole path?

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2019 08:27:13 +1300

Hi Fernando,

> follow two different paths, at the same time. That doesn't seem to be

I agree. That's why I am seriously asking whether we should recall
draft-ietf-6man-segment-routing-header-26 from the RFC Editor in order
to resolve this. Either (a) there MUST be at most one SRH in a packet,
or (b) the semantics and conflict resolution for multiple SRHs need to
be specified.

At the moment we (6MAN) are on track to publish a Proposed Standard RFC
that leaves this ambiguous, and SPRING has a draft in WGLC that assumes (b).

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Dec 2019 15:47:07 -0500

Hi Brian & Fernando & Ron

> that leaves this ambiguous, and SPRING has a draft in WGLC that assumes

  I am in line with your thinking and that how would the cost process two
SRH from a technical standpoint and how does the code know which SRH to use
for normal processing and which to use for TI-LFA fast reroute processing.

Since TI-LFA is deployment it is somehow working.

My guess is it’s coded such that the last SRH inserted is the one used.  So
In a normal state you are always using the 1st SRH segment list for you
traffic engineered hop by hop path. At the PLR node you have a “backup”
path pre programmed which is your standby TI-LFA path to the egress PQ
node.  So only at the PLR node does it have a NNH next next hop backup
calculation so only on that node and additional hops to the PQ node
junction point is the 2nd SRH programmed as backup and in use.  Once you
hit the PQ node the fast reroute detour is completed and PSP pop occurs if
that backup 2nd SRH eh header.

At that point you proceed as normal BAU using the 1st EH insertion done on
the SR source PE node.

I had to tear down my SR-MPLS & SRv6 lab test bed quite unfortunately, but
hope to have it back online soon so I can do some further debugging and
analysis as when you hit the PLR node doing the post convergence
calculation preprogrammed backup path how does it know which header to use.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Dec 2019 21:32:17 +0000

Brian,

When a protocol specification ignores a "should" recommendation , it SHOULD provide justification for doing so. Otherwise, the "should"  recommendationis meaningless.

Over the years, I have seen the following types of justification:

- Necessary: It is not possible to implement this protocol while conforming to the recommendation.
- Necessary optimization: It is not possible to make this protocol perform acceptably while conforming to the recommendation.
- Necessary simplification: It is not possible to operate and debug this protocol while conforming to the recommendation
- Unacceptable: I am ignoring this recommendation without offering any justification.

                                                              Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, December 9, 2019 8:02 PM
To: [email-masked]; Ron Bonica <[email-masked]>; '6man' <[email-masked]>
Subject: Re: Extension Header Insertion

That's "should", which in a non-RFC2119 document like RFC 8200, means "should".
It's not "must". So while I would prefer that the relevant SRH document justifies the exception, there isn't a breach of a mandatory requirement.

Yes

Unnecessary, IMHO.

    Brian

> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!VVSnZbHvCIx_b38GQZlY56-9iDtMPmXOpRPtPMb01i3KNpg23G-0z
> JIjIsiGNEzd$

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Dec 2019 21:49:54 +0000

Folks,

Adding to Brian's question, assume that the SR ingress node creates a packet that contains an SRH. In  that SRH,

- SL[0] : Locator is Node A and function is END.DT4. The ARG cause the packet to be forwarded into VPN RED.
- SL[1] : Locator is Node B and  function is END

Node B inserts another SRH before the original SRH. In that SRH:

- SL[0] : Locator is Node D and function is END.DT4. The ARG cause the packet to be forwarded into VPN BLUE.
- SL[1] : : Locator is Node E and function is END

In this case, the second SRH contradicts the first by causing the packet to be forwarded into a different VPN. Which SRH takes priority?

                                                                                    Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, December 9, 2019 8:21 PM
To: [email-masked]; Ron Bonica <[email-masked]>; '6man' <[email-masked]>
Subject: What if? [was Re: Extension Header Insertion]

       Segments Left=2
       Last Entry=2
       Flags=0
       Tag=0
       Segment List[0]=S3
       Segment List[1]=S2
       Segment List[2]=S1

and the second one is

       Segments Left=1
       Last Entry=1
       Flags=0
       Tag=0
       Segment List[0]=S4
       Segment List[1]=S5

Regards
   Brian Carpenter

On 10-Dec-19 14:02, Brian E Carpenter wrote:
> It's not "must". So while I would prefer that the relevant SRH 
> document justifies the exception, there isn't a breach of a mandatory requirement.
>   
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>> 6__;!!NEt6yMaO-gk!QcxrCDx88HILxijExwq_3hhEqP955MgFkB_g5T4Bb4T_FuZjRvj
>> 4jdITZ69rOB93$

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Dec 2019 22:04:10 +0000

Hi Brian.

I do believe that “assumption” you mention in draft-ietf-spring-network-programming is to be removed as a result of the last call discussion on spring@.

As I mentioned in a separate thread, RFC8200 states "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times”, the ‘assumption’ could been seen as a reminder of that requirement, but I don’t think thats necessary either.

There is no draft adopted by SPRING nor 6MAN that proposes multiple SRH be added to a packet.

If 6MAN intends to adopt a standards track definition of SRH insertion, then that document would need to fully describe the possible ramifications, including this one.  This we know, and are having much lively discussion on it.  I think we are safe to never have it ’sneak in’ without 6man having a say :)

Darren

On Dec 10, 2019, at 2:27 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Hi Fernando,

  Brian

      Segments Left=2
      Last Entry=2
      Flags=0
      Tag=0
      Segment List[0]=S3
      Segment List[1]=S2
      Segment List[2]=S1

and the second one is

      Segments Left=1
      Last Entry=1
      Flags=0
      Tag=0
      Segment List[0]=S4
      Segment List[1]=S5

Thanks,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 13:30:29 -0500

> I made that up and it's obviously nonsense, but if this is allowed why aren't the rules for processing conflicting SRHs described in draft-ietf-6man-segment-routing-header-26? Do we need to recall…

It would seem to me that this is not allowed.

What would be the semantics of a packet with two SRHs?

P.S.: If it had been allowed, it would have been explicitly allowed in
the SRH draft. -- you can't explicitly forbid all the possible
combinations of things that people might come up with... and there's an
existing recommendation against sending multiple instances of EHs in
RFC8200.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:02:40 -0500

On 10/12/19 14:27, Brian E Carpenter wrote:
[....]
> that leaves this ambiguous, and SPRING has a draft in WGLC that assumes (b).

FWIW, I don't mind doing that.

That said, it would seem to me that some folks are operating in a mode
where there are twisting specs to mean whatever  they want them to mean.
And there's no sensible amount of energy that can mitigate that other
than relevant  chairs and ADs trying to steer the discussions back on
the "sensible"/serious track.

P.S.: e.g. It seems the same group of folks that had argued that there
was ambiguity in rfc2460 wrt header insertion are now arguing that if
you are in the segment list of a RH, you are allowed to insert/remove
EHs. Seriously?
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:07:00 -0500

> - Unacceptable: I am ignoring this recommendation without offering any justification.

+1

Indeed, we are moving in a direction in which one wonders what's the
point of 6man publishing specs, and of folks reading them, if they can
be ignored and updated at will, without any rationale. And it's very sad.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2019 13:50:52 +1300

Thanks Darren. I will hold off on the spring draft until we see a new version, since several of us are simply repeating ourselves at this point.

>    before a Routing header and once before the upper-layer header).

I now think that either that "should" should be a "must", or there
should be an explicit statement that only one routing header is
allowed. The complexities of multiple routing headers are endless.

What do others think?

Regards
   Brian Carpenter

On 11-Dec-19 11:04, Darren Dukes (ddukes) wrote:
>> On Dec 10, 2019, at 2:27 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Fernando,
>>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Dec 2019 20:12:02 -0500

> allowed. The complexities of multiple routing headers are endless.
[ Of hats, I have none... ]

I think that not having RFC2119 language in this section is very
unfortunate, and creates a situation where different people read
different things into it (and are convinced that their interpretations
are clearly the right ones....)

I personally think that the spirit behind the Postel principle
applies, and that the should is a prohibition against there being more
than one, and that if receivers happen to do something sane in this
case, it is close to luck, not spec.

I'm not religious, but this seemed apropo:
"Then Abimelek called Abraham in and said, “What have you done to us?
How have I wronged you that you have brought such great guilt upon me
and my kingdom? You have done things to me that should never be done.”
- Genesis 20:9
:-P

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 23:07:47 -0500

+1

FWIW, this is irrespective of the current discussion we're having.

(There was a related I-D targetted at 6man, which for some reason
vanished, by at least one author from Cisco, IIRC)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 23:11:27 -0500

> are clearly the right ones....)

+1 . Although I think RFC8200 should have employed RFC2119 language
everywhere.

> case, it is close to luck, not spec.

+1 on this one. That said, the requirement to process any weird
combination eventually means lots of unnecessary code and analsys to
handle weird combinations (such as the one being discussed) that should
actually never happen.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Dec 2019 00:51:09 -0500

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:

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

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.

I am part of the rtgwg as well as most all the other internet and routing
area WGs.  I don’t mind mentioning to the authors of this draft  the issue
with the RFC 8200 violation.

I can CC you and others on this thread and the 6man and Spring chairs on
the email.  Please let me know if you think I should proceed so we can get
to the root of the eh insertion issue fixed in TI-LFA draft.

Once that is fixed we can get the Spring drafts updated into compliance as
well and finally proceed with PR WGLC.

Kind regards,

Gyan

On Tue, Dec 10, 2019 at 11:30 PM Fernando Gont <[email-masked]> wrote:

> >> Thanks Darren. I will hold off on the spring draft until we see a new
> version, since several of us are simply repeating ourselves at this point.
> >>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Dec 2019 11:50:15 +0000

> On 11 Dec 2019, at 05:51, Gyan Mishra <[email-masked]> 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 <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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 11 Dec 2019 09:11:02 -0800

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 <[email-masked]> wrote:
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2019 08:29:29 +1300

On 12-Dec-19 00:50, Stewart Bryant wrote:
> 
> 
>> On 11 Dec 2019, at 05:51, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Warren,
>>
>> Just a thought.
>>

Very true. MPLS allows label stacking. IPv6 does not (intentionally) allow
routing header stacking, but it does allow IPv6-in-IPv6 stacking, a.k.a.
encapsulation.

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Dec 2019 18:14:49 -0500

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 <[email-masked]>
wrote:

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

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Dec 2019 18:27:22 -0500

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 <[email-masked]> wrote:

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

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 11 Dec 2019 15:46:17 -0800

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 <[email-masked]>, wrote:
> 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.
>
> > > 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.
> > >
> > > 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].
> > > 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 <[email-masked]> wrote:
> > > > > Stewart,
> > > > >
> > > > > /rtgwg chair hat on

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Dec 2019 01:51:51 -0500

Will do.

Regards,

Gyan

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

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

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Dec 2019 12:40:03 +0000

> On 11 Dec 2019, at 19:29, Brian E Carpenter <[email-masked]> wrote:
> 

.. and  that is an unconditionally safe approach.

EH insertion is an optimisation and as with all optimisations we may not know of fully understand the consequences for a long time.

- Stewart