Hi PK, Please check inline below.
From: spring <[email protected]> On Behalf Of Przemyslaw Krol Sent: 30 March 2019 11:09 To: [email protected] Cc: [email protected] Subject: [spring] draft-ietf-idr-segment-routing-te-policy-05 - EXP NULL imposition Greetings, I have two minor comments regarding section 2..4.4 2.4.4. Explicit NULL Label Policy Sub-TLV The policy signaled in this Sub-TLV MAY be overridden by local policy. [pk] Wouldn't something like 'The behavior signaled in this Sub-TLV MAY be overridden by local configuration/implementation/etc' be better? In this daft's context policy has a defined meaning and 'signalling a policy' or 'local policy' may be confusing. [KT] I agree. I would suggest “The behaviour signalled in this sub-TLV MAY be overridden by local configuration.” Also, do you find useful listing such local behaviors or is it too implementation specific? The reason I'm asking is because I've seen 3 ways of handling automatic EXP NULL push (either available already or in development/discussion): [KT] IMHO it is implementation specific – but I will let the authors of draft-ietf-spring-segment-routing-policy decide if they want to put some non-normative text in that document. Also such text (even if we were to add it) does not seem suitable for this BGP document since it is possible that down the line we introduce something similar to ENLP in PCEP and the actual instantiation of the SR Policy is subject matter of the SR Policy Architecture draft. - based on Endpoint's AF (if packet's AF doesn't match Endpoint's AF -> PUSH EXP NULL) [KT] This sounds good since the controller is indicating based on it’s selection of the endpoint. Alternately, the controller itself could include the exp-null as part of the SID list. - based on the AF of SIDs/labels in the Segment List (if packet's AF doesn't match SID AF -> PUSH EXP NULL) [KT] I am not sure if it is always possible for the headend to determine this (e.g. consider multi-domain). It would be better for the controller to indicate this explicitly since it is the one that has computed the path and is aware of what is being used. - always assume PUSH for IPv6 (which also means always assume IPv4-only dataplane) - always assume PUSH for IPv4 (which also means always assume IPv6-only dataplane) [KT] The above two may be selected as well based on implementation support/capabilities or what is enabled. Each of these behaviors make assumptions depending on the primary use case and perhaps having them documented (and potentially referred to as Option A, Option B, etc or something similar) would help avoiding confusion when discussing with vendors. [KT] IMHO this is very much implementation specific. There may be a default option that an implementation chooses when valid ENLP is not given or exp-null label not included but then it may also give a config knob. Not sure if giving them names helps. But again, I will leave it to the authors of draft-ietf-spring-segment-routing-policy on how they would like to incorporate this. PS: I assume the Type number assignment will be handled by the ongoing effort Ketan has mentioned in the context of policy name Sub-TLV but just in case wanted to call this out too. [KT] We are still awaiting the code-point allocations (suggestions have been provided already). Thanks, Ketan thanks, pk -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
