Hi Thomas,
I've clarified a few points inline.
Thank you,
--
Sergey
From: thomas.g...@swisscom.com
Sent: Tuesday, September 1, 2020 12:55 AM
To: Fomin, Sergey (Nokia - US/Mountain View) ;
ketant=40cisco@dmarc.ietf.org
Cc: l...@ietf.org; spring@ietf.org; ops...@ietf.org
Subject: RE: [spring]
Hi Brian,
Many thanks for the time you took to do a thorough review, please see inline
below with [PC].
Cheers,
Pablo.
-Original Message-
From: Brian Weis via Datatracker
Sent: jueves, 27 de agosto de 2020 5:14
To: sec...@ietf.org
Cc: draft-ietf-spring-srv6-network-programming@iet
May be I was not very clear. My only ask is we must Recommended "BGP next hop
and SRV6 service SID for a BGP route must be derived from the same locator"
So that we no need to check the reachability to BGP nexthop and then check the
reachability to SRV6 service SID
>From the draft section
>"5
2nd try,
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? If so, wouldn't the PSP/USP cause an SRH that has not yet
been processed to be deleted?
-Karthik
Juniper
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? If so, wouldn't the PSP/USP cause an SRH that has not yet
been processed to be deleted?
- Karthik
Non-Juniper
_
Hi Sergey,
Thanks for the feedback. I am fully in line with your comment.
* Maybe we should consider adding a generic type 'Segment Routing' w/o
extra details if this might become an implementation challenge?
I would be interested to understand what extra details you would include in
this
Hi Ketan,
Thanks a lot for the feedback. So far Sergey feedbacked in favor to keep IE46
and SrSidType being separate. Lets see which opinion others have on the list.
* Also, from an operational perspective (looking holistically), we have LSP
ping/trace tools specified for MPLS (including S