Pablo,
Assume the following packet:
* Destination address is a uSID container
* Next header is an SRH
In this case, you wouldn't process the SRH until you process every uSID in the
uSID container. Do I have this much right?
So, if any uSID in the container specified the PSP or USP flavor, you would
delete an SRH that has not yet been processed.
Do I have this right?
Ron
Non-Juniper
From: spring <[email protected]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, September 9, 2020 4:13 AM
To: G. Sri Karthik Goud <[email protected]>; [email protected]
Cc: Swamy SRK <[email protected]>
Subject: Re: [spring] PSP and USP uN Flavors
[External Email. Be cautious of content]
Hi Karthik,
Please see inline.
Cheers,
Pablo.
From: spring <[email protected]<mailto:[email protected]>> On
Behalf Of G. Sri Karthik Goud
Sent: miércoles, 26 de agosto de 2020 0:30
To: [email protected]<mailto:[email protected]>
Cc: Swamy SRK <[email protected]<mailto:[email protected]>>
Subject: [spring] PSP and USP uN Flavors
Folks,
In draft-filsfils-spring-net-pgm-extension-srv6-usid, a uN represents an
instruction (END, END.T) instantiated on a node. Can that instruction have a
PSP or USP flavor?
[PC] The uN behavior is a new behavior. This behavior is defined in
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-07#section-4.1.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-07*section-4.1.1__;Iw!!NEt6yMaO-gk!XvwFr3yI1zJSgxdaBosAVTHRDz18s-XKUbIl5WNI3Vg7dDeNiCt0bMK1PFKEVCPJ$>
The uN behavior may be combined with the PSP, USP or USD flavors. Same applies
to the uA behavior.
You have the full list of behaviors in Section 9 of the draft.
If so, wouldn't the PSP/USP cause an SRH that has not yet been processed to be
deleted?
[PC] No. Leveraging the terminology defined in Section 2 of the draft: the
PSP/USP/USD is only executed when you get to the Last uSID of the uSID
Container.
Please have a look at the uN pseudocode in the latest revision of the draft
(rev 7). I believe the pseudocode is clearer than in previous revisions.
Thanks, and let me know if unclear.
- Karthik
Non-Juniper
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
