Re: [Pce] F and S bit in draft-ietf-pce-segment-routing
Hi Cheng,
Not an author, but as a document shepherd for this one -
The alphabets assigned to the bits do not have to expand to a keyword in the
description, even though that is the usual practice for readability purpose.
I am not sure why the authors picked "F" but it did not matter to me while
reviewing, what mattered was the description and usage of the bit.
Might be interesting to note that we have similar cases when you scan the flag
registries in our IANA page - https://www.iana.org/assignments/pcep/pcep.xhtml
And regarding setting of both flags, yes - that is not allowed and we have
this text -
If a PCC receives an SR-ERO subobject in which the S and F bits are
both set to 1 (that is, both the SID and NAI are absent), it MUST
consider the entire ERO invalid and send a PCErr message with Error-
Type = 10 ("Reception of an invalid object") and Error-Value = 6
("Both SID and NAI are absent in SR-ERO subobject").
I encourage authors to put forward their perspective.
Thanks!
Dhruv
On Wed, Aug 21, 2019 at 8:57 AM Chengli (Cheng Li) wrote:
>
> Hi authors,
>
>
>
> I am a little bit confusing of F and S bit in SR-ERO subobject.
> https://tools.ietf.org/html/draft-ietf-pce-segment-routing-16#section-4.3.1
>
>
>
> What is F standing for ?
>
>
>
> and how about S ? S for SID?
>
>
>
> It seems like S and F bit can not be set at the same time, correct?
>
>
>
> Thanks,
>
> Cheng
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR poll on draft-sivabalan-pce-binding-label-sid-07
Hi Hari, I am not aware of any IPR applicable to this draft. Thanks, Cheng From: Hariharan Ananthakrishnan [mailto:h...@netflix.com] Sent: Wednesday, August 21, 2019 11:40 AM To: Siva Sivabalan (msiva) ; cfils...@cisco.com; jefftant.i...@gmail.com; jonathan.hardw...@metaswitch.com; stef...@previdi.net; Chengli (Cheng Li) Cc: pce@ietf.org Subject: IPR poll on draft-sivabalan-pce-binding-label-sid-07 Hi Authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR poll on draft-sivabalan-pce-binding-label-sid-07
Hi Hari, I’m not aware of any IPR applicable. Regards, Jeff > On Aug 20, 2019, at 23:40, Hariharan Ananthakrishnan wrote: > > Hi Authors, > > In preparation for Working Group last call on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] IPR poll on draft-sivabalan-pce-binding-label-sid-07
Hi Authors, In preparation for Working Group last call on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] F and S bit in draft-ietf-pce-segment-routing
Hi authors, I am a little bit confusing of F and S bit in SR-ERO subobject. https://tools.ietf.org/html/draft-ietf-pce-segment-routing-16#section-4.3.1 What is F standing for ? and how about S ? S for SID? It seems like S and F bit can not be set at the same time, correct? Thanks, Cheng ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
Yes, support. Binding SID is very useful in many use cases, such as inter-domain/Multi-domain routing, SR policy, tunnel stitching, etc. Also, as descripted in this document, Huawei has implemented the mechanism. Since the text is mature, I support this WG adoption. Best regards, Cheng as a co-author. -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: Wednesday, August 21, 2019 1:45 AM To: pce@ietf.org Cc: pce-chairs Subject: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07 Hi WG, This email begins the WG adoption poll for draft-sivabalan-pce-binding-label-sid-07 [1]. Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. One of the chairs did a pre-adoption review [2] and authors posted a new revision. Note that there are known implementations. This adoption poll will end on 6th September 2019. Thanks! Dhruv (for the chairs) [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07 [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
As co-author support adoption. Preemptively - not aware of any IPR Cheers, Jeff On Aug 20, 2019, 1:45 PM -0400, Dhruv Dhody , wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-sivabalan-pce-binding-label-sid-07 [1]. > > Should this draft be adopted by the PCE WG? Please state your reasons - Why / > Why not? What needs to be fixed before or after adoption? Are you willing to > work on this draft? Review comments should be posted to the list. > > One of the chairs did a pre-adoption review [2] and authors posted a new > revision. Note that there are known implementations. > > This adoption poll will end on 6th September 2019. > > Thanks! > Dhruv (for the chairs) > > > [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07 > [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
Hi WG, This email begins the WG adoption poll for draft-sivabalan-pce-binding-label-sid-07 [1]. Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. One of the chairs did a pre-adoption review [2] and authors posted a new revision. Note that there are known implementations. This adoption poll will end on 6th September 2019. Thanks! Dhruv (for the chairs) [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07 [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] [Lsr] Solicit feedback on draft-ietf-lsr-pce-discovery-security-support-01
Hi Qin, I didn't see any response to this email, so I thought I should chip in with some (old, old, old) memories and context. tl;dr I am generally supportive of this work, but I think a little fine-tuning is needed. If I recall correctly, the situation when 5088 and 5089 were produced was that there was mission creep. The initial idea was to discover the existence of PCE-capable routers in the network, but it was quickly realised a specific address might be preferable for reaching the PCE, so there was need for the PCE Discovery TLV to contain an address, and it was decided to encode it as a TLV. Then the rot set in and we determined there were some other useful pieces of information to encode. And then we thought that it would be helpful to have an array of capability bits. At this point the IGP working groups started to get worried. As Les and Acee noted, the concern was that we would be carrying "large" amounts of data in the IGP that was not directly related to the primary purpose of the IGP (packet routing) or even the secondary purpose (TE). We had a bit of a fight on our hands at this stage because the PCE implementers had already built stuff, and the IGP "purists" were digging in. So we agreed to stabilise with "this far and no further" and the lines in 5088/9 that say: No additional sub-TLVs will be added to the PCED TLV in the future. If a future application requires the advertisement of additional PCE information in OSPF, this will not be carried in the Router Information LSA. The idea was that it would be OK to define new capability bits, but not to add more TLVs. I don't recall being delighted by this outcome at the time, but it certainly allowed us to move forward. It seemed to me that PCEs were not the only devices exchanging non-routing information in the IGP, and if there was a concern about volume of data or convergence time, then this seemed a bigger problem that needed a more general resolution. On the other hand, IETF consensus is what it is. The approach that others have taken in this situation is to add flags as needed, but to put the additional discovery information in the PCEP Open message. Thus, at a high level, a PCC can decide whether there is any point in opening a PCEP session with a PCE, but may have to try the session to find out exactly what options are available and might, at that time, discover that the PCE is not suitable. Looking at your draft, the addition of the two bit flags is easy and uncontroversial. It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you to want to change the RFCs. And I think you have a special case here because using the TCP security mechanism, the PCEP Open message would come too late to exchange the relevant information. That is, you need the security information to set up the secure TCP session before the PCEP Open messages can be exchanged. This point could usefully be made more clear in the document. That is, why you cannot use the alternate mechanism for exchanging PCE characteristics and capabilities. After that has been done, I think that it would be reasonable to allow the approach you are describing subject to LSR WG consensus. (The alternative, which is perfectly acceptable within the architecture and within some operational environments, is configuration. But configuration doesn't work in the larger use cases, and another mechanism would constitute a third way of exchanging PCE information, and that sounds ridiculous.) However, while I think that you should be allowed through the doorway, I don't think you should leave the door open behind you. That means that you should update 5088/9 to allow your new sub-TLVs, but you should leave in place the ruling that no more new sub-TLVs are allowed. I *think* that is what you're trying to do, but I don't think your Section 4 is the right way to do that - it is not necessary to make edits to the old documents to make this change, you can simply say... Section 4 of [RFC5088] states that no new sub-TLVs will be added to the PCED TLV, and no new PCE information will be carried in the Router Information LSA. This document updates RFC 5088 by allowing the two new sub-TLVs defined in this document to be carried in the PCED TLV of the for use in the Router Information LSA. Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED TLV, and no new PCE information will be carried in the Router CAPABLITY TLV. This document updates RFC 5089 by allowing the two new sub-TLVs defined in this document to be carried in the PCED TLV of the for use in the Router CAPABILITY TLV. Along the way, we're also going to need to do some work on Section 7. The whole point of your draft is to exchange information about security features, and that makes it highly sensitive if it can be attacked. For example, just toggling the two new capability bits can be a downgrade attack. And tweaking the content of the new TLVs would, I imagine, enable man-in-the-middle
