Subject: Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-00

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 10 Sep 2019 15:07:16 +0000

Hi Parag,

Inline.

Cheers,
Pablo.

From: spring <[email-masked]> on behalf of Parag Kaneriya <pkaneria=[email-masked]>
Date: Friday, 26 July 2019 at 10:58
To: SPRING WG <[email-masked]>
Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-00

Hello,

I have gone though this draft and below are my thought with respect to CRH comparison given in the draft

1)      At ingress node has to more work by gathering individual micro sid . for example  Node A configured with micro sid  FC00::A000/32 Node B with FC00::B0000/32.

Now at ingress node has to concinnated these 2 micro sid into one  FC00::A000:B000: followed by of carrier  which is 0000 .

So this is more complex stuff introduced at ingress while programing path.

PC: False. This is control plane work done once.

2)      Even shifting of bit are hardware friendly ,  it is still more work then normal CRH processing  where additional CPU cycle to form new Destination by playing with bits and from new destination header.
PC: False. Are you kidding?
uSID- One IPv6 lookup (ingress), one shift (SID processing), one IPv6 lookup (egress) is much less than:
CRH- One IPv6 lookup (ingress), one CRH label lookup in a new database, one IPv6 copy to dest, one IPv6 lookup (egress).
That’s 3 lookups. Not to mention all the destination option header parsing before AND after CRH.
SRH/uSID processing is already supported in many h/w platforms including merchant silicon. Has CRH and its related DOHs been actually implemented and publicly demonstrated at linerate on h/w ASICs?

Regards
Parag

Juniper Business Use Only