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

[Alexandre Petrescu <[e-mail]>]

Le 09/12/2019 à 16:45, Tom Herbert a écrit :
[...]
> Is there agreement that proper use of IP encapsulation with EH is
> functionally equivalent to EH insertion?

I do agree.

In programming terms, IP encapsulation means to insert an IP header, 
which is a C struct like any other EH.

Conceptually, sending a packet from A to C through B can be

Enc:       src=A|dst=B[src=A|dst=C|payload]
or
EH removal: src=A|dst=B|EH|payload, and then src=A|dst=C|payload

It's the same thing.

Alex

> 
> 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
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>