Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
John: Hope you are doing well. We authors know draft-ietf-lsr-pce-discovery-security-support-05 is one of WG drafts you are responsible for. We just want to give you a quick heads up, we have addressed all comments from directorate review including secdir review. Unfortunately secdir review can not be updated to reflect the real status but just note the review has completed. I know this is a bug, but it is not a big deal. Please let us authors know if anything is needed from us to move this work forward. Thanks in advance. -Qin -邮件原件- 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 发送时间: 2021年8月27日 21:27 收件人: Tero Kivinen ; Yaron Sheffer 抄送: Qin Wu ; tom petch ; draft-ietf-lsr-pce-discovery-security-support@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Tero, I see the review is now marked "Completed". This was what I wanted. Thanks, Acee On 8/27/21, 9:11 AM, "Tero Kivinen" wrote: Yaron Sheffer writes: > Hi Acee, > > I honestly don't know how to do it, and if I even can unless you > send a new review request. We do not really update the reviews, but we do assign draft for two reviews, i.e., one during the last call and one before the telechat (I will not reassign it for telechat if there is no need to do rereview, i.e., original review was ready and/or nothing major changed in the draft since the review). > Copying Tero who's an expert on this. > > To clarify: my review of -05 still stands, but it has been addressed > by -07. As area directors will see the review email thread and if the there is comment there that review comments have been addressed in later drafts that is enough, so no need to update the review. Note, that even when the reviewer thinks his comments have been addressed, the area director might have different view on that matter, i.e., they might still comment on the issues found during the telechat. > > Thanks, > Yaron > > > On 8/19/21, 20:55, "Acee Lindem (acee)" wrote: > > Hi Yaron, > > Thanks for the review. Can you update the status of the SECDIR review? > > https://datatracker.ietf.org/doc/review-ietf-lsr-pce-discovery-security-support-05-secdir-lc-sheffer-2021-08-05/ > > Thanks, > Acee > > On 8/17/21, 3:15 AM, "Yaron Sheffer" wrote: > > Looks good to me. Thank you! > > Yaron > > On 8/17/21, 03:17, "Qin Wu" wrote: > > Sorry for late followup, here is the update, the diff is > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06 > Yaron, let authors know if your comments are addressed in v-06. > Thanks! > > -Qin > -邮件原件- > 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] > 发送时间: 2021年8月17日 4:33 > 收件人: Qin Wu ; tom petch ; Yaron Sheffer ; sec...@ietf.org > 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org > 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 > > Hi Qin, > > Can you publish a revision so that Yaron assure it satisfies his comments? > > Thanks, > Acee > > On 8/12/21, 9:21 PM, "Qin Wu" wrote: > > Thanks Acee and Tom for good suggestion, we will take them into account. > > -Qin > -邮件原件- > 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] > 发送时间: 2021年8月12日 1:18 > 收件人: tom petch ; Yaron Sheffer ; Qin Wu ; sec...@ietf.org > 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org > 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 > > I'd also recommend changing, "key names" to "key-ids or key-chain names" since this is what is actually being advertised. > Thanks, > Acee > > On 8/10/21, 11:53 AM, "tom petch" wrote: > > From: Lsr on behalf of Yaron Sheffer > Sent: 10 August 2021 14:57 > > So let me suggest: > > > An offlist suggestion for you to consider > > OLD > Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in > [RFC5310]
Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi, Ketan: I recommend that in Broadcast/NBMA network, the BFD session is bootstrapped after the DR/BDR election(but before the OSPF adjacency establishment). That is, only the BFD session between DRother and DR/BDR is checked. This can avoid many useless BFD sessions between DRothers and also accomplish your goal to assure the reliable OSPF adjacency establishment. Aijun Wang China Telecom > 在 2022年2月8日，22:34，Ketan Talaulikar 写道： > > > Hi Aijun, > > The primary purpose of BFD session monitoring between two DROther routers is > for fast detection so fast-reroute mechanisms can be triggered locally. This > is the normal case. If such BFD sessions are not there, then there is a gap > between the time when either the DR detects that a DROther router is down and > then updates & floods its network LSA OR when the DRother routers learn the > same after the dead interval. Neither of them meet the typical requirements > of fast-reroute. > > There is a corner case where the DR has connectivity to the DRother routers > but the connectivity between the DRother routers is broken (e.g. consider an > emulated VPLS deployment). In such cases, the network LSA which provides the > topology input for SPF will not reflect any change, but the adjacency between > the DRother routers will remain down. However, OSPF on LAN depends on the > mutuality of connections between routers for the DR mechanism to work > effectively. Strict mode doesn't make much difference here. > > Thanks, > Ketan > > >> On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang wrote: >> Hi, Ketan: >> >> >> >> From: lsr-boun...@ietf.org On Behalf Of Ketan >> Talaulikar >> Sent: Monday, January 31, 2022 1:13 AM >> To: Aijun Wang >> Cc: lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee >> Lindem (acee) ; Albert Fu >> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - >> draft-ietf-lsr-ospf-bfd-strict-mode-04 >> >> >> >> Hi Aijun, >> >> >> >> There is a need for a BFD session to be established between neighboring >> routers which directly forward data between them to ensure reachability >> between them. That is my understanding of various implementations and >> deployments at operators. This is independent of the strict mode of >> operation. >> >> [WAJ] What is the action when the BFD session between the DRothers is not >> BROUGHT UP or DOWN then? >> >> >> >> Perhaps you have a different requirement for "optimization of BFD sessions >> on multi-access networks"? If so, it would be clearer if you could put that >> requirement/proposal together as a draft for the WG to review. Also, that >> would be in any way independent of this specification since what you are >> referring to is the base use of BFD by OSPF. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang wrote: >> >> Hi, Acee and Ketan: >> >> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode. >> >> What I want to express is that you brought up the full mesh BFD sessions >> among the routers within such network type. Is it necessary to bring some of >> them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency are >> established between the DRother and DR/BDR router? >> >> If the BFD session is bootstrapped after the OSPF adjacency is established, >> there will be no such extra/useless BFD sessions >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> On Jan 30, 2022, at 02:45, Acee Lindem (acee) wrote: >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, >> >> If you want a per-neighbor state and route, you have to use P2MP. This scope >> of this draft isn’t to try and make NBMA/Broadcast model something that it >> is not. This is should be common knowledge and the draft needn’t address it. >> Those of us who remember ATM emulated LANs (which were not always >> symmetrically reliable) will recall using P2MP on an inherently multi-access >> network. >> >> Acee >> >> >> >> From: Aijun Wang >> Date: Saturday, January 29, 2022 at 3:46 AM >> To: 'Ketan Talaulikar' >> Cc: "lsr@ietf.org" , >> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" >> , 'Albert Fu' >> , Acee Lindem >> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - >> draft-ietf-lsr-ospf-bfd-strict-mode-04 >> >> >> >> Hi, Ketan: >> >> OK, then back to my original question: >> >> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the >> OSPF adjacency(between the DRother and DR/BDR)? >> >> If not, then the traffic between these DRothers will be lost; If yes, it >> seems strange, because the BFD session between the DRother and DR/BDR may be >> still UP. >> >> I think here there are some mismatch between the BFD sessions and the OSPF >> adjacency in Broadcast/NBMA network, then some clarification for the >> procedures are needed. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang
Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Muthu, I don't have the data for BFD strict-mode interop over virtual links. However, p2p unnumbered is commonly deployed and I'll let my co-author clarify on interop. Thanks, Ketan On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal < muthu.a...@gmail.com> wrote: > Hi Ketan, > > Sure, looking forward to the clarification in the draft on multi-hop BFD.. > > Just curious, are there interoperable implementations for OSPF multi-hop > BFD strict mode for virtual links or p2p unnumbered interfaces? > > Regards, > Muthu > > On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar > wrote: > >> Hi Muthu, >> >> When we say a "link" here, it is in the context of the OSPF interface and >> neighbor FSM. My understanding is that this term includes virtual links as >> well. As such, we can add some text in the introduction section to clarify >> the same and also put a reference to RFC5883 for BFD multi-hop use for >> VLINKs. >> >> I hope that works for you. >> >> Thanks, >> Ketan >> >> >> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal < >> muthu.a...@gmail.com> wrote: >> >>> Hi Ketan, >>> >>> Thanks for your response.. >>> >>> The draft says: >>> >>>This document defines the B-bit in the LLS Type 1 Extended Options >>>and Flags field. This bit is defined for the LLS block included in >>>Hello and Database Description (DD) packets and >>> *indicates that BFD is enabled on the link* and that the router >>> requests strict-mode for BFD. >>> >>> >>> You don't enable multi-hop BFD on a link, instead you enable it b/w two >>> (multi-hop) routers, right? >>> >>> How about replacing it with: >>> indicates that (1) single-hop BFD [RFC5881] is enabled on the link in >>> case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD >>> [RFC5883] is enabled between the neighbors in case of virtual links and >>> point-to-point unnumbered interfaces. >>> >>> Also, add a note at the beginning of the draft that BFD refers to both >>> single-hop and multi-hop BFD when not explicitly specified.. >>> >>> Regards, >>> Muthu >>> >>> On Sun, Jan 30, 2022 at 10:40 PM Ketan Talaulikar >>> wrote: >>> Hi Muthu, Thanks for your review and your support. Regarding your question, I would like to clarify that this document doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed for virtual links, there would need to be a BFD multi-hop session and the same would apply to p-t-p unnumbered. However, I am not sure what specific applicability or operations need to be called out for Strict Mode of operations for those links. Thanks, Ketan On Sun, Jan 30, 2022 at 12:52 PM Muthu Arul Mozhi Perumal < muthu.a...@gmail.com> wrote: > Hi, > > I support the draft. A quick question: > Should it describe the applicability of the mechanism over OSPF > virtual links and unnumbered interfaces? With virtual links, one would > have > to establish a multi-hop BFD session, so it is slightly different from a > BFD operational standpoint. For e.g, capability to support single-hop BFD > may not translate to the capability to support multi-hop BFD.. > > Regards, > Muthu > > On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) 40cisco@dmarc.ietf.org> wrote: > >> LSR WG, >> >> >> >> This begins a two week last call for the subject draft. Please >> indicate your support or objection on this list prior to 12:00 AM UTC on >> February 11th, 20222. Also, review comments are certainly welcome. >> >> Thanks, >> Acee >> >> >> ___ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Aijun, The primary purpose of BFD session monitoring between two DROther routers is for fast detection so fast-reroute mechanisms can be triggered locally. This is the normal case. If such BFD sessions are not there, then there is a gap between the time when either the DR detects that a DROther router is down and then updates & floods its network LSA OR when the DRother routers learn the same after the dead interval. Neither of them meet the typical requirements of fast-reroute. There is a corner case where the DR has connectivity to the DRother routers but the connectivity between the DRother routers is broken (e.g. consider an emulated VPLS deployment). In such cases, the network LSA which provides the topology input for SPF will not reflect any change, but the adjacency between the DRother routers will remain down. However, OSPF on LAN depends on the mutuality of connections between routers for the DR mechanism to work effectively. Strict mode doesn't make much difference here. Thanks, Ketan On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang wrote: > Hi, Ketan: > > > > *From:* lsr-boun...@ietf.org *On Behalf Of *Ketan > Talaulikar > *Sent:* Monday, January 31, 2022 1:13 AM > *To:* Aijun Wang > *Cc:* lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; > Acee Lindem (acee) ; Albert Fu > *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Hi Aijun, > > > > There is a need for a BFD session to be established between neighboring > routers which directly forward data between them to ensure reachability > between them. That is my understanding of various implementations and > deployments at operators. This is independent of the strict mode of > operation. > > *[WAJ] What is the action when the BFD session between the DRothers is not > BROUGHT UP or DOWN then?* > > > > Perhaps you have a different requirement for "optimization of BFD sessions > on multi-access networks"? If so, it would be clearer if you could put that > requirement/proposal together as a draft for the WG to review. Also, that > would be in any way independent of this specification since what you are > referring to is the base use of BFD by OSPF. > > > > Thanks, > > Ketan > > > > > > On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang > wrote: > > Hi, Acee and Ketan: > > No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode. > > What I want to express is that you brought up the full mesh BFD sessions > among the routers within such network type. Is it necessary to bring some > of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency > are established between the DRother and DR/BDR router? > > If the BFD session is bootstrapped after the OSPF adjacency is > established, there will be no such extra/useless BFD sessions > > Aijun Wang > > China Telecom > > > > On Jan 30, 2022, at 02:45, Acee Lindem (acee) wrote: > > > > Speaking as WG member: > > > > Hi Aijun, > > If you want a per-neighbor state and route, you have to use P2MP. This > scope of this draft isn’t to try and make NBMA/Broadcast model something > that it is not. This is should be common knowledge and the draft needn’t > address it. Those of us who remember ATM emulated LANs (which were not > always symmetrically reliable) will recall using P2MP on an inherently > multi-access network. > > Acee > > > > *From: *Aijun Wang > *Date: *Saturday, January 29, 2022 at 3:46 AM > *To: *'Ketan Talaulikar' > *Cc: *"lsr@ietf.org" , " > draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" < > draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' < > af...@bloomberg.net>, Acee Lindem > *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Hi, Ketan: > > OK, then back to my original question: > > If one of the BFD session(between DRothers) is DOWN, will it bring DOWN > the OSPF adjacency(between the DRother and DR/BDR)? > > If not, then the traffic between these DRothers will be lost; If yes, it > seems strange, because the BFD session between the DRother and DR/BDR may > be still UP. > > I think here there are some mismatch between the BFD sessions and the OSPF > adjacency in Broadcast/NBMA network, then some clarification for the > procedures are needed. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org *On Behalf Of *Ketan > Talaulikar > *Sent:* Saturday, January 29, 2022 4:22 PM > *To:* Aijun Wang > *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert > Fu ; Acee Lindem (acee) 40cisco@dmarc.ietf.org> > *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Hi Aijun, > > > > The choice of the term "adjacency" was not accurate in my previous > response to you. I meant "neighborship". > > > > That said, the substance of my response still remains the same. > > > > Thanks, > >
