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

[Gyan Mishra <[e-mail]>]

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