Hi Tarek, See inline...
From: Pce [mailto:[email protected]] On Behalf Of Tarek Saad Sent: 20 March 2019 21:46 To: Dhruv Dhody <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp Hi Dhruv, Thanks for the reply. I understand your point; however, my concern is not so much on the PCEP protocol object definition, but more on the attribute(s) alignment for the different protocol cases. I'll quote an example you gave for BSID TLV definition in both drafts.. draft-ietf-idr-segment-routing-te-policy defines "S", and "I" flags but those are missing from draft-sivabalan-pce-binding-label-sid * S-Flag: This flag encodes the "Specified-BSID-only" behavior. It is used by SRPM as described in section 6.2.3 in [I-D.ietf-spring-segment-routing-policy<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#ref-I-D.ietf-spring-segment-routing-policy>]. * I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is used by SRPM as described in section 8.2 in [I-D.ietf-spring-segment-routing-policy<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#ref-I-D.ietf-spring-segment-routing-policy>]. [[[Dhruv Dhody]]] Your point is well taken, I would ask the authors of the SR documents to do this exercise. I see some overlap in authors as well who could take the lead. But due care should be taken in the description within the PCEP and BGP context, because BSID as currently described in PCEP is attached to a candidate path v/s BSID in BGP is described towards the full SR policy. Similarly, draft-sivabalan-pce-binding-label-sid defines BT=0/1 behaviors but those are missing from the other draft.. [[[Dhruv Dhody]]] You are right. This aligns to the C bit in SR-ERO. A question to BGP draft authors on why this is not in BGP! There may be other cases for SR-ERO too - e.g. missing "SR Algorithm", etc. [[[Dhruv Dhody]]] I guess this would be needed when a PCE does not prepare the label stack but provide NAI and flex algo is enabled. Looks like nobody uses this yet and thus was not noticed :). We could define a new NAI type to handle this case. Thanks for engaging and providing instances where there are mismatch. I would encourage authors to do an alignment check. Thanks! Dhruv I noticed a trend in LSR WG to define sub-TLVs that can be resused by multiple IGP protocols (e.g. the sub-TLVs defined in draft-ietf-lsr-pce-discovery-security-support).. and I was wondering if this approach could be leveraged here too. Regards, Tarek From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Date: Wednesday, March 20, 2019 at 11:14 AM To: Tarek Saad <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp Hi Tarek, As a individual WG member, I think reusing BGP sub-TLV in PCEP in this case(*) is problematic, mainly because - (1) PCEP already has some other objects and TLVs which were defined much before the BGP SR Policy work, such as - - SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV) - TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV) (2) PCEP has a very specific format for all its TLVs as per https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP does not follow that. (3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or candidate path) we carry its associated Policy information in the ASSOCIATION object. That said, it is important that fields and encoding are aligned between BGP and PCEP and I would request the authors to make sure that is the case. Thanks! Dhruv (*) We were able to do this successfully in case of Flowspec On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad <[email protected]<mailto:[email protected]>> wrote: Hi authors, The I-D "draft-ietf-idr-segment-routing-te-policy" defines sub-tlvs for SR Policy attributes that are carried in BGP (see below) for SR policy and its attributes. Ideally, with PCEP can achieve what is supported with BGP signaling and hence can leverage the most of those definitions? Is there a reason not to? 2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2...4>. SR Policy Sub-TLVs . . . . . . .. . . . . . . . . . . . . 9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9> 2.4.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.1>. Preference Sub-TLV . . . . . . . . . . . . . . .. . . 9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9> 2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>. Binding SID Sub-TLV . .. . . . . . . . . .. . . .. . . . 10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10> 2.4.3<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3>. Segment List Sub-TLV . . . . . . . . . . . . . .. . . 11<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-11> 2.4.3.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.1>. Weight Sub-TLV 2.4.3.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.2>. Segment Sub-TLV 2.4.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4>. Explicit NULL Label Policy Sub-TLV . . . . . . .. . . 27<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-27> 2.4.5<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>. Policy Priority Sub-TLV . . . . . . . . .. . . . . . . 28<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28> 2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>. Policy Name Sub-TLV . .. . . . . . . . . .. . . .. . . . 29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29> Regards, Tarek _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
