Re: What is necessity for SRH, and other EH, insertion/removal?

[Tom Herbert <[e-mail]>]

On Sat, Dec 7, 2019 at 7:37 PM Gyan Mishra <[e-mail]> wrote:
>
>
>
> On Sat, Dec 7, 2019 at 7:30 PM Tom Herbert <[e-mail]> wrote:
>>
>> On Sat, Dec 7, 2019 at 3:48 PM Gyan Mishra <[e-mail]> wrote:
>> >
>> >
>> > Tom
>> >
>> > Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt
>> >
>> > The initial proposal for SRv6 was EH insertion of SRH routing type 4 header in flight which is a violation of RFC 8200 which we 6man gave tremendous push back.
>> >
>> > Spring came back with Encapsulation at the ingress PE of the SR domain and removal at the PSP or USP node upon leaving the SR domain.
>> >
>> > What was added to that was in order for the hop by hop traffic engineering of the flow to happen the EH insertion still has to happen with the SRH routing header type 4 that has the instruction set PSSI function of explicit hop by hop Routing the flow through the SR domain.
>>
>> Why does it need to happen? As you mention, there was pushback
>> inserting extension headers at ingress, but that same pushback is
>> applicable for inserting extension headers at any intermediate nodes.
>> So if encapsulation is acceptable to solve the problem at ingress to
>> the domain, why isn't acceptable for that same technique to be used at
>> nodes internal to the domain or other intermediate nodes?
>
>
>      I believe the 6in6 encapsulation with SRH eh insertion at the ingress or any intermediate node within the SR domain is a solid technical workaround that would allow SRv6 to function and provide the hop by hop traffic engineered path.  Every time an EH insertion is required an encapsulation would occur with the SRH eh added each time.  Like pealing an onion the encapsulation wrappers would be removed at each egress point until you reach the 2nd to last PSP node or last USP node at which point all encapsulations and EHs would be removed that were inserted and the IPv6 packet would now be forwarded leaving the SR domain as it entered.
>
> The reason for the intermediate node EH insertion encapsulation workaround technically from an SRv6 perspective is for Ti-LFA node and path protection NNH path PLR (point of local repair) to egress PQ node where the encapsulation is then removed that was added at the PLR intermediate node.  There maybe cases with SRv6 tunnel stitching that may require more then 2 encapsulations that could possibly occur.  I would say in most use cases in general you would have 2 encapsulations.
>

Gyan,

I see two possibilities for showing necessity of a protocol:

1) The protocol uniquely solves a problem for which there is no other
feasible means to solve the problem.
2) The protocol solves a problem in a better way than any of the alternatives.

For EH insertion, encapsulation with the EH that would otherwise be
inserted has been proposed as an alternative several times. In fact
this was required in early versions of draft-ietf-6man-rfc2460bis:

"Extension headers must never be inserted by any node other than the
source of the packet.  IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in
[RFC2473]."

Is there agreement that proper use of IP encapsulation with EH is
functionally equivalent to EH insertion?

If there is agreement that EH insertion doesn't satisfy #1, then
necessity of EH insertion would be a matter of showing that the
benefits of it outweigh the disadvantages relative to IP encapsulation
with EH.

Tom



> Gyan
>>
>>
>> Tom
>>
>> >
>> > Hope that explains the technical reason for the SRH routing type 4 header that has to be inserted and removed along with the encapsulation.
>> >
>> > With tunneling to your comment that is not technically traffic engineering.  Traffic engineering is hop by hop explicit pathing of a flow which done via MPLS TE or SR via SR-TE or Ti-LFA.
>> >
>> > Cheers,
>> >
>> >
>> > Gyan
>> >
>> > Sent from my iPhone
>> >
>> > On Dec 7, 2019, at 4:38 PM, Tom Herbert <[e-mail]> wrote:
>> >
>> > 
>> > Gyan,
>> >
>> > Traffic engineering is not a new concept, and tunneling across a transit domain has long been an effective method. So the question remains: why can't that be used in segment routing use case?
>> >
>> > So far, no one has said why it won't work. I'm really hoping someone will stand up and clearly articulate why that or any other alternative doesn't work such EH insertion is necessary. At that point, we might be able have a productive discussion about how to move forward.
>> >
>> > Tom
>> >
>> >
>> > On Sat, Dec 7, 2019, 1:15 PM Gyan Mishra <[e-mail]> wrote:
>> >>
>> >>
>> >>
>> >> Because SRv6 is touted to be the Swiss Army knife so to speak for any use case requiring traffic engineering that’s where it gets much more complicated with EH insertion and violation of RFC 8200.
>> >>
>> >> Cheers,
>> >>
>> >> Gyan
>> >>
>> >> On Sat, Dec 7, 2019 at 4:00 PM Gyan Mishra <[e-mail]> wrote:
>> >>>
>> >>>
>> >>> Not to confuse the subject but this is an email  I had sent to Spring/6man/BESS WGs related to comment on inter AS considerations “inter domain” and that we should be able to apply the same Inter-AS L3 vpn  features since its truly a bgp service construct overlay on top of the SRv6 domain.
>> >>>
>> >>> To that end with TEAS WG as well we with traffic engineering IP TE we are looking at taking the RSVP
>> >>> feature and benefits and applying then to SRv6 as well as SR-MPLS to both SR-TR and Ti-LFA.
>> >>>
>> >>> That is reason I think why the concepts of PSP was being applied to the SRv6 specification.
>> >>>
>> >>> Post below:
>> >>>
>> >>> Here are some details related to existing Inter domain MPLS which has come a long ways since inception decades ago.
>> >>>
>> >>> Inter AS options A, B, C & CSC
>> >>> https://tools.ietf.org/html/rfc4364#section-10
>> >>>
>> >>> Inter AS option AB
>> >>> https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/
>> >>>
>> >>> Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS.  Simple and works if isolation is required between providers.  Does not scale. Multicast Is simple as MVPN profiles do not need to match as PIM over the NNI inter AS link glues the two MVPN domains together.
>> >>>
>> >>> Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter AS link.  Highly scalable.  RT filtering is enabled by default on all PEs so has to be disabled on ASBR PE. Retain RT policy applied can filter and RTs and don’t have to accept all RTs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS.
>> >>>
>> >>> Inter AS Option C: End to End LSP with BGP-LU (label switched unicast) enabled on inter AS link data plane path.  All SP PE loopback FEC destinations  must be exchanged imported between SPs and iBGP-LU PE to RR for SP loops exchanged to have label binding when advertised over eBGP LU inter AS. VPNV4 peering next-hop-unchanged for control plane update so end to end LSP can build between any to any PE between SPs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN FIB.
>> >>>
>> >>> Inter AS Option AB Hybrid of Option A and B with single control plane VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces per customer VRF.  Scales well as control plane is provided via single BGP peer. AB provides additional security with VRF isolation feature.  No importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.
>> >>>
>> >>> Of the 4 inter AS options available today with MPLS Option A very simple and seamless and works well if you have a minimal number of VRFs.  Option B and AB both are highly scalable and AB works well if security is a concern.  Option C is a good option for enterprises as well as service providers that have a close trust relationship.
>> >>>
>> >>> In your introduction section can you provide some details I have mentioned of the existing MPLS inter domain options.  As you mentioned the importing of millions of prefixes that would only be with Option C and it would only be a million if each provider had a million PE loopback to import.
>> >>>
>> >>> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to use the traditional mpls inter as options.
>> >>>
>> >>> As for SRv6 since it uses the IPv6 data plane as far as inter domain that can be stitched with SRv6 using Option B style but IPv6 dataplane in place of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6 would ride on top.  I guess you could do Option C style and advertise the PE FEC loopbacks between domains for an end to end SID list similar to an end to end LSP do the PSP PHP would not happen until you hit the last or next to last node in the chain of domains.
>> >>>
>> >>> My guess is with both SRv6 and SR-MPLS you could literally take all for inter AS options and use them as the bottom service BGP label would be the same it’s just that you are swapping out the MPLS topmost label MPLS IPv4 data plane with SRv6 IPv6 data plane.
>> >>>
>> >>> Thank you
>> >>>
>> >>> Gyan
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Dec 7, 2019 at 3:40 PM Gyan Mishra <[e-mail]> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> Tom
>> >>>>
>> >>>> Since we are drawing similarities between MPLS and SR both have the domain concept.
>> >>>>
>> >>>> The big difference between SR and MPLS is that each MPLS router maintains state in the P and PE nodes where with SR each PE or P along the source routed path does not maintain state.
>> >>>>
>> >>>> That is where with SR the source routing function on the ingress PE node of the SR domain created the source routed SR label stacking path with SR-MPLS topmost label.  In IPv6 forwarding plane case with SRv6 is accomplished with the SRH routing header type 4 which has the Segment list. So with SRv6 the one hop prior to egress node of the SRv6 domain being the PSP node end “egress P”in MPLS terms and the last  hop node in the USP scenario is the “egress PE” last node in the SRv6 domain.
>> >>>>
>> >>>> PHP in MPLS came about historically as with older MPLS routers instead of putting the burden on the last node to pop all labels “ultimate” hopping with explicit null the default behavior has always been for all vendors to do the PHP function.
>> >>>>
>> >>>>
>> >>>> There are use cases primarily for QOS and maintaining EXP scheduling in the last hop from PE to P the concept of “pipe node” came about which is the explicit null option which allows the topmost label to be maintained on the last hop to the egress PE.
>> >>>>
>> >>>> I agree that that with SRv6 we are dealing with the IPv6 data plane and not MPLS data plane so its truly like apple and oranges.
>> >>>>
>> >>>> However from a functional scenario in reality SPs can now deploy SRv6 core replacement of the legacy MPLS LDP label switching.
>> >>>>
>> >>>> From an SP core L3 VPN perspective the BGP AFI vpnv4 vpnv6 ipv4 IPv6 all AFI/SAFI can now sit right on top of this new IPv6 data plane model with SRv6.
>> >>>>
>> >>>> I believe from the BESS working group it has been mentioned that China SPs has 7+ deployments of SRV6.
>> >>>>
>> >>>> So as you enter a domain you perform MPLS imposition or now SRH eh  insertion and when you exit the domain you do PHP/UHP for MPLS or PSP/USP for SRv6.
>> >>>>
>> >>>> Hope this helps clarify in bridging the gap between WGs 6man, Spring, BESS, LSR, RTG, MPLS.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Gyan
>> >>>>
>> >>>> On Sat, Dec 7, 2019 at 12:17 PM Tom Herbert <[e-mail]> wrote:
>> >>>>>
>> >>>>> Pulling this out into a separate thread. Pertinent questions are:
>> >>>>>
>> >>>>> Why is extension header insertion and removal at necessary?
>> >>>>>
>> >>>>> Why isn't the proposed alternative of IPIP encapsulation sufficient?
>> >>>>> (where the encapsulating headers contain the extension headers that
>> >>>>> would otherwise be inserted)
>> >>>>>
>> >>>>> Please note, I'm asking for the technical justification of the
>> >>>>> protocol design, saying that it's necessary because it's already being
>> >>>>> deployed isn't useful in this regard.
>> >>>>>
>> >>>>> Tom
>> >>>>>
>> >>>>> --------------------------------------------------------------------
>> >>>>> 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
>> >>
>> >>
>
> --
>
> 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
>
>