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

[Gyan Mishra <[e-mail]>]

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