Yes/Support. This draft provides a concise and practical way to perform path
mtu detection and verification.
Best Regards,
Xiao Min
原始邮件
发件人：ReshadRahman(rrahman)
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 09:06
主 题 ：BFD WG adoption for draft-haas-bfd-large-packets
Hello BFD WG,
I support WG adoption of this draft. Use of the demand mode for p2p LSP
monitoring is feasible and required.
Best Regards,
Xiao Min
原始邮件
发件人：JeffreyHaas
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,
Hi Carlos,
My answers to your two questions are as follow:
In section 6.6 of RFC5880, just after the text you quoted, it says "One
possible mechanism is the receipt of traffic from the remote system; another is
the use of the Echo function." So I'm not sure what's your real concern.
In
Hi Jeff & Reshad,
On Feb 18th I've already requested a small time slot to present
draft-xiao-bfd-geneve-00, you may miss it, could you pls add it to the agenda?
BFD for Geneve (draft-xiao-bfd-geneve) Presenter: Xiao Min Duration: about
5 min
Thanks,
Xiao Min
原始邮件
Hi Jeff,
Thank you for the arrangement.
I'll follow your guidance on preparing the slides.
Thanks,
Xiao Min
原始邮件
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：rtg-bfd@ietf.org ;
日 期 ：2019年03月13日 23:22
主 题 ：Re: IETF 104 - BFD agenda posted
Xiao Min,
I've added you to the
Hi Reshad,
I support this draft to be published, it provides a simple and elegant
extension for BFD to verify path MTU.
By the way, if further we'd like to achieve a fine-grained process control
while using BFD to verfiy or detect path MTU, with the cost of a more complex
extention to
Hi Jeff and Reshad,
From my personal perspective, I don't think we should require BFD for VxLAN to
support Echo mode, because as I know, although the final standard is still on
the way, many vendors including my company have already implemented BFD for
VxLAN, and it seems that works fine,
Hi all,
I support all the three drafts to be published. They're useful enhancements to
base BFD protocol, short and well-written.
BRs,
Xiao Min
原始邮件
发件人：SantoshPK
收件人：Ashesh Mishra ;
抄送人：rtg-bfd@ietf.org ;
日 期 ：2019年09月13日 01:10
主 题 ：Re: Working Group Last Call on BFD
Hi Jeff,
I talked to implementor of my company, and I got the feedback that the
provision of peer ip address is necessary, that means different ip address can
be provisioned to different BFD session. As to VNI, there is no restriction on
which VNI to choose. I guess this behavior is
Hi Anoop,
Thanks for your comments.
Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?
Best Regards,
Xiao
Hi Joel,
Thanks for your comments.
I don't think the VNI could own IP address and MAC address, if the BFD messages
are originated and terminated at the VNI, then what addresses would be used by
the BFD messages?
As to the VAP, RFC8014 defines it as below:
"On the NVE side, a VAP is a
Hi Anoop,
Due to the fact that a variety of Tunnels could be used under the NVO3
architecture, as an example, below figure illustrates the format of MPLS packet
over Geneve Tunnel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Hi Jeff,
I could be one minutes taker if no others experienced volunteered.
Best Regards,
Xiao Min
原始邮件
发件人：JeffreyHaas
收件人：rtg-bfd@ietf.org ;
抄送人：Reshad Rahman (rrahman) ;
日 期 ：2019年11月10日 03:28
主 题 ：Re: IETF-106 agenda?
Working Group,
We will be attempting to
Yes, what I discussed with Anoop was on Greg's option #3.
Respecting BFD over VxLAN, option #2 and #3 both are ok to me, I have no
preference.
Respecting BFD over Geneve, option #2 and #3 both are ok to me, although I
personally prefer #3.
Best Regards,
Xiao Min
原始邮件
Hi Anoop,
Sorry for the late response, I just come back from vacation.
The use case is that the network between the VM and the NVE is an MPLS network,
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC
address and/or 802.1Q VLAN. When two such kind of MPLS
Hi Anoop,
Normally, it is. While Tenant Systems connect to NVE through IP routing network
or MPLS forwarding network, it is not.
Best Regards,
Xiao Min
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org
;rtg-bfd WG ;
日 期 ：2019年10月10日
Hi Anoop,
Please see my response inline with [XM].
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Hi Anoop,
In this use case there is no forwarding happens between the MPLS and non-MPLS
parts, would this use case be prohibited?
If the answer is yes, then I agree that all Tenant Systems attached to a common
NVE MUST share a VAP so long as they connect to the same VN, although in
Hi Joel,
I fully agree to your analysis.
One major difference between VxLAN and Geneve (or VxLAN-GPE) is that VxLAN
doesn't support multi-protocol payload, and VxLAN only supports payload of
Ethernet frame. Although VxLAN specification was developed outside NVO3 WG, I
believe VxLAN may
Hi Anoop,
I don't know such a draft that describes MPLS over Geneve, but I believe the
following figure derived from figure 1 of RFC8014 would help, in the following
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are
assumed belonging to the same VNI, so two BFD
Hi Anoop,
In the use case illustrated in below figure, do you think Tenant System1 and
Tenant System2 can be within the same VN? do you think NVE1 and NVE2 can
encapsulate the same VNI in the packets sent from Tenant System1 and Tenant
System2?
. . +--+-+
. .--|NVE1|
Hi Anoop,
Thanks for your reply to my question.
It's clear that we have different views on this case, could you please direct
me to the text(if any) of RFC/draft that supports your statement?
Any thoughts from others?
Best Regards,
Xiao Min
原始邮件
发件人：AnoopGhanwani
收件人：肖敏10093570;
Hi BFD WG,
A new BFD individual draft has been submitted recently, link as below.
https://tools.ietf.org/html/draft-xiao-bfd-padding-alteration-00
This short draft proposes the Padding Poll Sequence, to keep the BFD session up
when BFD padding alters.
Your review and comments
Hi all,
I support WG adoption of this draft (as co-author).
At the same time, I support to change its status to Proposed Standard, and add
tag of "Updates RFC5880".
Best Regards,
Xiao Min
原始邮件
发件人：JeffreyHaas
收件人：rtg-bfd@ietf.org ;
日 期 ：2020年08月04日 21:04
主 题 ：Adoption call
Hi Jeff,
I think the candidate minutes reflect the discussion during the BFD session
very well, and I have no suggestion for revision on it.
Just a comment w.r.t BFD for Geneve to test non-management VNI, we have been
attempting to address the issues found by IESG discussion on BFD for
BFD WG,
We've uploaded a new revision to address comments from Jeff.
Some editorial changes are incorporated too.
Looking forward to your further review and comments.
Best Regards,
Xiao Min
--原始邮件--
发件人：internet-dra...@ietf.org
收件人：i-d-annou...@ietf.org ;
Jeff,
I agree to your analysis.
In the current draft, I've tried to make the desired behavior clear, at the
same time, reuse the already defined BFD procedure as much as possible.
As always, I'm open to any suggestions and comments. Although I disagree to a
specific suggestion sometimes, the
Greg, Jeff,
It looks that you converge on comparison between S-BFD Echo and Unaffiliated
Echo.
What I want to point out is, allowing using standalone BFD/S-BFD Echo without
periodically transmitted BFD/S-BFD Control packets, doesn't mean it's
Unaffiliated Echo.
In RFC 5880 section 3.2 the 4th
Hi Greg,
Thanks for your thorough review and insightful questions.
I hold the pen for draft-ietf-bfd-unaffiliated-echo, so I'd like to give my
reply first.
As you may have known or not, before this draft was posted, we ever tried to
submit an errata instead of an I-D. However, under the
Thank you Jeff! A very clear description on the core motivation and current
situation.
>From the author's perspective, I'd like to remove the reference to BBF TR-146
>if it's becoming a blocking issue instead of a supporting argument.
Best Regards,
Xiao Min
Jeff,
I have no objection to the comparison, please go on.
One thing I want to emphasize is that, whether DC use case (brought up by
draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by
BBF TR-146), the key requirement is that the peer system is totally
BFD-Unaware, in
Jeff,
That's OK. I'll hold on for your further judgement.
Just to clarify, when this document's predecessor
(draft-wang-bfd-one-arm-use-case-00) was brought up to IETF, the proponents
didn't know any of BBF related prior art, that means their original work was
not inspired by BBF TR-146. At
Hi Greg,
Please see inline with [XM].
Best Regards,
Xiao Min
--原始邮件--
发件人：GregMirsky
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-unaffiliated-e...@ietf.org;rtg-bfd WG;
日 期 ：2021年11月17日 23:48
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Hi Xiao
Jeff,
So, that's not new to everyone, great!
At this time, my proposal is to proceed with draft-ietf-bfd-unaffiliated-echo,
publish it as planned.
Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：肖敏10093570;
Dear Ketan,
Thanks for your review and thoughtful comments.
Please see inline.
Original
From: KetanTalaulikar
To: draft-ietf-bfd-unaffiliated-e...@ietf.org
;
Cc: rtg-bfd@ietf.org ;Jeffrey Haas ;
Date: 2023年09月22日 22:55
Subject: Comments on draft-ietf-bfd-unaffiliated-echo-08
Hello Authors,
Hi Greg, Ketan,
Many thanks for the productive discussion.
Thank you Ketan for the newly suggested text, which looks good to me.
I've incorporated Ketan's new text into the -10 version just posted. Link as
below.
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-10
Cheers,
Hi Greg,
Thank you for the reply.
Please see inline with [XM-2]>>>.
Original
From: GregMirsky
To: 肖敏10093570;
Cc: ketant.i...@gmail.com ;rtg-bfd@ietf.org
;draft-ietf-bfd-unaffiliated-e...@ietf.org
;
Date: 2023年09月28日 05:13
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
Hi
Hi Ketan,
Thank you for the suggested text, very helpful.
I've just posted a new revision that incorporates all your comments. Link as
below.
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
Please see inline with [XM-2]>>>.
Original
From: KetanTalaulikar
To:
Hi Greg,
Please see inline.
Original
From: GregMirsky
To: Ketan Talaulikar ;
Cc: 肖敏10093570;rtg-bfd WG
;draft-ietf-bfd-unaffiliated-e...@ietf.org
;
Date: 2023年09月27日 02:21
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
Hi Ketan,
Thank you for sharing your interpretation of
Jeff,
Please see inline...
Best Regards,
Xiao Min
Original
From: JeffreyHaas
To: Reshad Rahman ;
Cc: BFD WG ;Alexander Vainshtein
;Nitsan Dolev ;Shell
Nakash ;James Lian ;
Date: 2022年10月20日 20:52
Subject: Re: A missing read/write attribute in RFC 9314?
On Oct 19, 2022, at
Jeff, Sasha, Reshad, et al.,
Please see inline...
Best Regards,
Xiao Min
Original
From: JeffreyHaas
To: Alexander Vainshtein ;
Cc: Reshad Rahman ;BFD WG ;Nitsan Dolev
;Shell Nakash ;James Lian
;
Date: 2022年10月20日 04:17
Subject: Re: [EXTERNAL] Re: A missing read/write
Hi BFD WG,
A new version of draft-ietf-bfd-unaffiliated-echo has been submitted to keep it
from expired.
The current draft has addressed all received comments, please review it and
provide your further comments.
Thanks,
Xiao Min
--Original--
From:
Hi Matthew,
Thank you for concluding the extended WG last call.
I've posted the -08 revision to address all the agreed WG last call comments.
Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-08
Best Regards,
Xiao Min
Original
From:
Hi Matthew,
Would you please conclude the extended WG LC for draft-ietf-nvo3-bfd-geneve?
Best Regards,
Xiao Min
Original
From: 肖敏10093570
To: ReshadRahman ;
Cc: n...@ietf.org ;rtg-bfd@ietf.org
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 10:24
Subject: Re: Extending WG
Jeff,
Thank you for the quick reply.
Please see inline...
Original
From: JeffreyHaas
To: 肖敏10093570;
Cc: Reshad Rahman ;BFD WG ;Alexander
Vainshtein ;Nitsan Dolev
;Shell Nakash
;james.l...@rbbn.com ;
Date: 2022年11月04日 19:22
Subject: Re: A missing read/write attribute in RFC 9314?
Jeff,
Thank you for the quick reply.
Please see inline...
Original
From: JeffreyHaas
To: 肖敏10093570;
Cc: Bocci, Matthew (Nokia - GB) ;n...@ietf.org
;rtg-bfd@ietf.org ;
Date: 2022年11月04日 19:20
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks
Xiao Min,
Hi Reshad,
Thank you for the quick reply.
Please see inline [XM-2]...
Original
From: ReshadRahman
To: 肖敏10093570;
Cc: n...@ietf.org ;rtg-bfd@ietf.org
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 04:12
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks
Hi Reshad,
Thank you for the thorough review and thoughtful comments.
Please see inline...
Best Regards,
Xiao Min
Original
From: ReshadRahman
To: NVO3 ;rtg-bfd@ietf.org ;Bocci, Matthew
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for
Jeff,
Thank you for the thorough review and thoughtful comments.
Please see inline...
Best Regards,
Xiao Min
Original
From: JeffreyHaas
To: Bocci, Matthew (Nokia - GB) ;
Cc: NVO3 ;rtg-bfd@ietf.org ;
Date: 2022年11月04日 08:11
Subject: Re: Extending WG LC for
Jeff,
To clarify ZTE's implementation, please see inline...
Original
From: JeffreyHaas
To: Reshad Rahman ;
Cc: BFD WG ;Alexander Vainshtein
;Nitsan Dolev ;Shell
Nakash ;James Lian ;
Date: 2022年11月04日 07:17
Subject: Re: A missing read/write attribute in RFC 9314?
[In an attempt to
Hi Abhinav,
When I come across your problem, the first idea coming into my mind is not
trying to change the source port for a BFD session, but to run multiple BFD
sessions between the two peers, using each BFD session to monitor a respective
ECMP path, and then the application would not
Jeff,
Please see inline...
Original
From: JeffTantsura
To: 肖敏10093570;
Cc: absri...@gmail.com ;alexander.vainsht...@rbbn.com
;rtg-bfd@ietf.org ;
Date: 2023年03月24日 16:48
Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to
facilitate auto recovery
That’s
Jeff,
Thank you very much for the insightful and detailed review and comments,
especially the proposed text, very helpful.
A new -06 revision to address your comments has just been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-06.
Please see inline for
Hi Jeff,
Please see inline...
Original
From: JeffTantsura
To: 肖敏10093570;
Cc: Abhinav Srivastava ;alexander.vainsht...@rbbn.com
;rtg-bfd@ietf.org ;
Date: 2023年03月27日 00:28
Subject: Re: [EXTERNAL] Can a BFD session change its source port to facilitate
auto recovery
Hi Xiao,
Reshad,
I consulted my colleague implementing BFD in ZTE, and I confirm the LocalDiag
would be reset once the session returns to Up.
Besides, at least two proprietary usages of Diag have ever been implemented,
one for bidirectional path consistency, another for OAM mapping.
Hope that
Dear BFD WG,
A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted, attempting
to address all the WGLC comments.
The main updates are as below.
* add a sentence to clarify that this document doesn't change the affiliated
BFD Echo function.
* change the order of section 2
Jeff, Aijun,
Thank you for the comments.
Please see inline...
Original
From: JeffreyHaas
To: Aijun Wang ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年04月07日 23:27
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Aijun,
> On Apr 6, 2023, at 8:53 PM, Aijun
Jeff,
Please see inline...
Original
From: JeffreyHaas
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org
;
Date: 2023年04月07日 23:32
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Xiao Min,
On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn
Jeff,
Please see inline...
Original
From: JeffreyHaas
To: 肖敏10093570;
Cc: Greg Mirsky ;rtg-bfd@ietf.org ;
Date: 2023年04月11日 01:34
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Xiao Min,
On Apr 9, 2023, at 10:42 PM,
wrote:
After
I am not aware of any IPR applicable to this document.
Best Regards,
Xiao Min
Original
From: JeffreyHaas
To: draft-ietf-bfd-unaffiliated-e...@ietf.org
;
Cc: rtg-bfd WG ;
Date: 2023年04月10日 23:27
Subject: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
Jeff,
Thank you for the comments.
Please see inline...
Original
From: JeffreyHaas
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org
;
Date: 2023年04月06日 22:28
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Xiao Min,
Thanks for addressing
Hi Sasha,
Please see inline...
Original
From: AlexanderVainshtein
To: Jeff Tantsura ;肖敏10093570;
Cc: Abhinav Srivastava ;rtg-bfd@ietf.org ;
Date: 2023年03月27日 08:55
Subject: RE: [EXTERNAL] Can a BFD session change its source port to facilitate
auto recovery
Jeff, Xiao and all,
Aijun,
Thanks for your support and review.
Please see inline...
Original
From: AijunWang
To: 'Jeffrey Haas' ;rtg-bfd@ietf.org ;
Date: 2023年04月04日 17:28
Subject: RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Support its forwarding.
The implementation and
Greg,
Thank you for the detailed reply.
I suspect I've known where your concern derive from, that's a misunderstanding.
Note that the Unaffiliated BFD Echo is NOT intended to replace the BFD Echo
function defined in RFC 5880.
I don't think an interoperability between a system using
Jeff,
Thank you for initiating WGLC on this draft per request of the authors.
I support progressing this draft to publication (as a co-author).
I agree with you that the draft could use very high scrutiny.
Note that I've posted version -06 attempting to address your last call
Dear Greg,
Thanks for sharing your thoughts, even if they're concerns.
Please see inline...
Original
From: GregMirsky
To: Jeffrey Haas ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年03月27日 13:40
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Dear Authors,I
Jeff, Greg,
Please see inline...
Original
From: JeffreyHaas
To: Greg Mirsky ;
Cc: draft-ietf-bfd-unaffiliated-e...@ietf.org
;rtg-bfd WG ;
Date: 2023年04月14日 04:10
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
Greg,
> On Apr 12, 2023, at 1:09 PM, Greg Mirsky
Hi Greg,
Thank you for the detailed review and comments, although I don't think your
comments justify your conclusion.
Please see inline...
Original
From: GregMirsky
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org ;
Date: 2023年04月29日 03:42
Subject: Re: Fw: New Version Notification for
Hi Magnus,
Thank you for the prompt reply.
A new version has just been posted to address your comments. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-11
I also cc BFD WG to see if some new ideas can be motivated by your good
observation.
Best
Dear BFD WG,
A new -08 version of Unaffiliated BFD Echo has just been posted. Link and Diff
as below.
This version is intended to address Greg's comments on -07 version of this
draft.
Many thanks to Greg for his thorough review and helpful comments.
Best Regards,
Xiao Min
Hi Greg,
Thank you for the continued discussion.
As to Standard vs Experimental/Informational, I've stated my opinion and no
more to add.
For the last two remaining discussion points, please see inline [XM-5]>>>.
Original
From: GregMirsky
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org ;
Hi Greg,
Please see inline...
Original
From: GregMirsky
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org ;
Date: 2023年05月10日 00:02
Subject: Re: Fw: New Version Notification for
draft-ietf-bfd-unaffiliated-echo-07.txt
Hi Xiao Min,thank you for your expedient response. Please find my follow-up
Hi Greg,
The points we have converged are trimmed, because I received a notice from
rtg-bfd-ow...@ietf.org that "Message body is too big".
Please see inline [XM-3]>>>.
Original
It is stated in the Abstract:
BFD Async procedures can be executed over
Hi Greg,
Thank you for the comprehensive and detailed discussion, which improves this
document in many aspects.
I'll post a new version draft after we reach agreement on the last few points.
Please see inline [XM-4]>>>.
Original
From: GregMirsky
To: 肖敏10093570;
Cc:
Hi Jeff, Reshad,
Thanks for the great summary!
Just one small update to the wiki, the title of
draft-ietf-bfd-unaffiliated-echo has been changed from "Unaffiliated BFD Echo
Function" to "Unaffiliated BFD Echo" since -03 version.
Cheers,
Xiao Min
Original
From: JeffreyHaas
To: rtg-bfd@ietf.
The suggestion from Jeff and Carlos seems reasonable to me, although I was not
involved in the former mailing-list discussion.
Best Regards,
Xiao Min
Original
From: CarlosPignataro
To: Jeff Haas ;
Cc: m...@ietf.org ;rtg-bfd@ietf. ;
Date: 2024年02月05日 11:35
Subject: Re: [mpls] Review of
Hi Jeff,
Thanks for resuming your work on this document, which seems to me a useful one.
Glad to work with you and Albert on incorporating
draft-xiao-bfd-padding-alteration-00 into draft-ietf-bfd-large-packets if
applicable.
Best Regards,
Xiao Min
Original
From: JeffreyHaas
To:
77 matches
Mail list logo
