[{"author": "~~dhruv~~dhody~~", "text": "https://notes.ietf.org/notes-ietf-113-pce?edit
", "time": "2022-03-22T12:03:33Z"}, {"author": "Boris Khasanov", "text": "How persistent adj-SID should be allocated? Which mechanism?
", "time": "2022-03-22T12:10:35Z"}, {"author": "Zhibo Hu", "text": "Strict bandwidth commitment per path to ensure no impact on the Service Level Agreement (SLA) due to changing network load from
other services.How did it do it?
", "time": "2022-03-22T12:13:53Z"}, {"author": "Ketan Talaulikar", "text": "@Boris, this comes from RFC8402 and the IGP RFCs. They are configured/provisioned (usually from within the SRLB). I think it might be covered in draft-ietf-isis-sr-yang
", "time": "2022-03-22T12:15:24Z"}, {"author": "Zafar Ali", "text": "@Zhibo This is done using local QoS policies at the routers and traffic marking for the Circuit Style SR traffic
", "time": "2022-03-22T12:18:49Z"}, {"author": "Boris Khasanov", "text": "Thanks @Ketan. yes, I know that they come from SRLB. Point was - it looks that they should be assigned in centralized way (i.e. from PCE/controller) by some mechanism like PCEP or Netconf
", "time": "2022-03-22T12:19:00Z"}, {"author": "Jie Dong", "text": "how to guarantee the set of bandwidth for a CS-SR path on a link? Do you need to allocate different SIDs for different paths?
", "time": "2022-03-22T12:19:19Z"}, {"author": "Zhibo Hu", "text": "@Zafar Ali, Does the router maintain per-path QoS queues?How do you mark it?
", "time": "2022-03-22T12:21:18Z"}, {"author": "Zafar Ali", "text": "@ Jie, No, there is only one Adj SID per link. The bandwidth guarantees are achieve using QoS constructs
", "time": "2022-03-22T12:21:46Z"}, {"author": "John Scudder", "text": "Sounds like the authors should work with the chairs (and AD if necessary...) to find a good home for this work. I agree with Dhruv's point.
", "time": "2022-03-22T12:22:09Z"}, {"author": "Ketan Talaulikar", "text": "@Boris, not via PCEP (AFAIK) but why not via Netconf since we have the YANG models.
", "time": "2022-03-22T12:22:18Z"}, {"author": "Haomian Zheng", "text": "This should not be PCEP-specific. Similar mechanism was designed for GMPLS a few years ago, refer to RFC8131 for more details.
", "time": "2022-03-22T12:22:36Z"}, {"author": "Andrew Stone", "text": "agreed with Dhruv, seems quite a general architecture guideline rather than protocol extensions (in this doc)
", "time": "2022-03-22T12:22:39Z"}, {"author": "Zafar Ali", "text": "@Zhibo, No - there is no per path QoS queues. The queues are per EXP, as usual (no change is required)
", "time": "2022-03-22T12:23:03Z"}, {"author": "Andrew Stone", "text": "@Zafar - if under some condition something happens which causes bandwidth to no longer be sufficient (ex: PCE is using telemetry to accurately verify bandwidth assignment), despite it being set to \"do not optimize\" - wouldn't one expect PCE to tear down a given path?
", "time": "2022-03-22T12:23:56Z"}, {"author": "Jie Dong", "text": "@Zafar, then how to distinguish traffic belonging to one CS path from the traffic of another path?
", "time": "2022-03-22T12:24:17Z"}, {"author": "Zhibo Hu", "text": "OK, @Zafar Ali, OK, thank you, maybe it didn't do what it claims to do.
", "time": "2022-03-22T12:24:31Z"}, {"author": "Zafar Ali", "text": "@Andrew please advise on the right home for the work. We will follow-up, accordingly
", "time": "2022-03-22T12:24:32Z"}, {"author": "Boris Khasanov", "text": "@ketan, yes- Netconf/Yang will work. But PCECC, IMO, could be even better (just one PCEP as transport for all)
", "time": "2022-03-22T12:25:14Z"}, {"author": "Andrew Stone", "text": "\"feels like\" an rtgwg or spring item
", "time": "2022-03-22T12:25:14Z"}, {"author": "Zafar Ali", "text": "@ Jie Customers set aside an EXP/ DHCP for the circuit style traffic. Traffic is marked using that EXP/ DHCP to differentiate the traffic belonging to the circuit style
", "time": "2022-03-22T12:25:51Z"}, {"author": "Cheng Li", "text": "I see a O-bit in RP object as per RFC5440, no sure that that can be reused
", "time": "2022-03-22T12:26:01Z"}, {"author": "Zafar Ali", "text": "@ Andrew The PCE performs the admission control to ensure bandwidth guarantees
", "time": "2022-03-22T12:27:36Z"}, {"author": "Andrew Stone", "text": "@zafar - their might still be uncontrolled traffic demands in the network
", "time": "2022-03-22T12:28:03Z"}, {"author": "Zafar Ali", "text": "@Andrew, there should never be uncontrolled traffic pushed for the circuit style - due to bandwidth admission control and traffic marking/ QoS policies to guarantee the allocated BW for the circuit style traffic. Yes, there can be uncontrolled traffic demands for other type of policies, which should not impact the circuit style traffic
", "time": "2022-03-22T12:31:05Z"}, {"author": "Jie Dong", "text": "@Zafar do you mean to reserve some dedicated TC/DSCP code points for CS style traffic? Will multiple CS paths share the same code point?
", "time": "2022-03-22T12:32:14Z"}, {"author": "dhruvdhody", "text": "Christian on mic
", "time": "2022-03-22T12:34:34Z"}, {"author": "dhruvdhody", "text": "no its samuel :)
", "time": "2022-03-22T12:34:53Z"}, {"author": "Zafar Ali", "text": "@ Jie, No new code point needed. On a per deployment basis, customer set aside an EXP/ DHCP (existing code points) for circuit style policies/ traffic. Yes, all CS paths share the same EXP/ DHCP marking.
", "time": "2022-03-22T12:36:05Z"}, {"author": "Vishnu Beeram", "text": "+1 to Dhruv's comment on using Policy Association
", "time": "2022-03-22T12:37:56Z"}, {"author": "Boris Khasanov", "text": "@Dhruv, pls send your last question to the list, to make sure that it won't be forgotten
", "time": "2022-03-22T12:40:09Z"}, {"author": "dhruvdhody", "text": "well sure it will be documented in the minutes too
", "time": "2022-03-22T12:40:34Z"}, {"author": "dhruvdhody", "text": "Huanan - i will send my comments on the list!
", "time": "2022-03-22T12:57:58Z"}, {"author": "Italo Busi", "text": "bye bye
", "time": "2022-03-22T13:01:22Z"}]