Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

2019-10-11 Thread xiao.min2
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;
抄送人:draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月12日 00:00
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Unless they are in the same broadcast domain (which does not appear to the 
case) they would not be in the same VNI.

Anoop




On Fri, Oct 11, 2019 at 2:18 AM  wrote:


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|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件


发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月11日 05:33
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月10日 15:47
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


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 ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月10日 05:33
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


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 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 :2019年10月09日 06:28
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


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, 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

2019-10-11 Thread Anoop Ghanwani
Hi Xiao Min,

Unless they are in the same broadcast domain (which does not appear to the
case) they would not be in the same VNI.

Anoop

On Fri, Oct 11, 2019 at 2:18 AM  wrote:

> 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|
> .  .  ||
> .  .  +--+-+
> .  . |
> .  L3 Overlay  .   ( ' )
> .Network   .(IP Routing)
> .  .   ( _ )
> .  . |
> ++
>|| Tenant |
>  ++ | System1|
>  |NVE2| ++
>  ||
>  ++
>|
>  ( ' )
>   (IP Routing)
>  ( _ )
>|
>++
>| Tenant |
>| System2|
>++
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人:*AnoopGhanwani 
> *收件人:*肖敏10093570;
> *抄送人:*draft-ietf-bfd-vx...@ietf.org ;
> nvo3@ietf.org ;rtg-bfd WG ;
> *日 期 :*2019年10月11日 05:33
> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Hi Xiao Min,
> Can you provide more detail on your scenario?  I'm having trouble figuring
> it out from the description below.  I need to know what subnets the tenants
> are in.
>
> Anoop
>
> On Thu, Oct 10, 2019 at 5:00 AM  wrote:
>
>> Hi Anoop,
>>
>>
>> Please see my response inline with [XM].
>> 原始邮件
>> *发件人:*AnoopGhanwani 
>> *收件人:*肖敏10093570;
>> *抄送人:*draft-ietf-bfd-vx...@ietf.org ;
>> nvo3@ietf.org ;rtg-bfd WG ;
>> *日 期 :*2019年10月10日 15:47
>> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
>> ___
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> Hi Xiao Min,
>>
>> In those cases, the term "VN" is used to talk about multiple IP
>> interfaces in a VRF.  The different interfaces would have to be different
>> VNIs.
>>
>> [XM] To be clear, I interpret VNI as Virtual Network Identifier that
>> should be present within VxLAN/Geneve header. Do you mean in the case
>> multiple Tenant Systems connect to multiple NVEs through IP routing
>> network, different NVEs must encapsulate different Virtual Network
>> Identifiers?
>>
>> In the mixed case (with MPLS and L2 hitting the NVE at different VAPs),
>> I'm not sure how it would work in the same VNI.  If you think it's
>> important, I think it may be worth writing it up.  If there's enough merit
>> in the use case, we can figure out how to run multiple BFD sessions on the
>> same VNI.
>>
>> [XM] As to the mixed case, I don't know whether there's enough merit, I
>> just raise it for discussion because it seems not being prohibited from the
>> NVO3 architecture point of view.
>>
>>
>> Anoop
>>
>>
>> Best Regards,
>>
>> Xiao Min
>>
>>
>> On Wed, Oct 9, 2019 at 11:06 PM  wrote:
>>
>>> 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 ;
>>> nvo3@ietf.org ;rtg-bfd WG ;
>>> *日 期 :*2019年10月10日 05:33
>>> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
>>> Hi Xiao Min,
>>> Normally, I think of a VNI as a broadcast domain.  The only way I can
>>> make sense of the picture below is to have a separate VNI for each MPLS
>>> interface on the NVE.
>>>
>>> Anoop
>>>
>>> On Tue, Oct 8, 2019 at 11:09 PM >> > wrote:
>>>
 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 RFC8014 it uses "can" but not "MUST". As a result, we should
 not allow multiple BFD sessions for the same VNI between two NVEs.

 If the answer is no, then we should allow multiple BFD sessions for
 the same VNI between two NVEs. I personally lean to this answer.


 Best Regards,

 Xiao Min
 原始邮件
 *发件人:*AnoopGhanwani 
 *收件人:*肖敏10093570;
 *抄送人:*Greg Mirsky ;did...@gmail.com <
 did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org <
 draft-ietf-bfd-vx...@ietf.org>;nvo3@ietf.org ;
 santosh...pallaga...@gmail.com  <
 santosh.pallaga...@gmail.com>;rtg-bfd WG ;Joel M.
 Halpern ;tsrid...@vmware.com >>> >;
 *日 期 :*2019年10月09日 06:28
 *主 题 :**Re: 

Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

2019-10-11 Thread xiao.min2
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|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件



发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月11日 05:33
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:draft-ietf-bfd-vx...@ietf.org ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月10日 15:47
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


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 ;nvo3@ietf.org 
;rtg-bfd WG ;
日 期 :2019年10月10日 05:33
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


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 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人:AnoopGhanwani 
收件人:肖敏10093570;
抄送人:Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;nvo3@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 :2019年10月09日 06:28
主 题 :Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


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 sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++





Re: [nvo3] draft-xiao-nvo3-bfd-geneve-00

2019-10-11 Thread xiao.min2
Hi Santosh,






Many thanks for your comments.




Please see my response inline with [XM].



原始邮件



发件人:SantoshPK 
收件人:nvo3@ietf.org ;rtg-bfd WG ;
日 期 :2019年10月04日 01:22
主 题 :draft-xiao-nvo3-bfd-geneve-00,



Hello Authors,Below are the comments on the draft. 

"[Ed.Note]: Use of O bit is still being discussed in the NVO3 WG, so
 the value is undetermined."
[SPK] In some of the implementation that are using BFD over GENEVE have already 
started using O bit to indicate this is OAM packet and these packets are not 
being forwarded. We may need to set this in the GENEVE header for compatibility 
and have extra information for the new implementation. Any thoughts? 
[XM] Fully agree. In the next revision, will change this sentence to "O bit 
SHOULD be set to 1, which indicates this packet contains a control message."

 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD 
sessions may be originating or terminating at one NVE, there needs to be a 
mechanism for demultiplexing received BFD packets to the proper session."


[SPK] BFD VXLAN https://tools.ietf.org/html/draft-ietf-bfd-vxlan-07 drafts 
there is good discussion going on if we need to define the motivation of the 
draft on what problem it solves if we have BFD per VNI. There are concerns 
about the scalability for the same. While we can still have BFD for subset of 
VNI or we can have BFD per VNI at sedate interval/demand mode and may use P/F 
sequence to poll when required. We can define supporting use case or when P/F 
sequence can be really used for example it can be used when data traffic for a 
given VNI has not been received for some duration. There should also be an 
option to run BFD session for management VNI along with BFD for per VNI. 

[XM] My thoughts are that BFD sessions should be originated and terminated at 
VAP which is defined in RFC8014, and it's still undetermined that whether all 
Tenant Systems attached to a common NVE MUST share a VAP so long as they 
connect to the same VN, which will result in the decision whether we should 
allow multiple BFD sessions for the same VNI, in this respect, we can align the 
statements for both draft-ietf-bfd-vxlan and this draft, alternatively, 
considering the major difference between VxLAN and Geneve that Geneve supports 
multi-protocol payload, we can also make different statements for 
draft-ietf-bfd-vxlan and this draft. Lastly, I don't see much benefit to employ 
P/F sequence here, certainly I'm open to further discussion on it.


 "Since multiple BFD sessions may be running between two NVEs, and multiple BFD 
sessions may be originating or terminating at one NVE, there needs to be a 
mechanism for demultiplexing received BFD packets to the proper session."



[SPK] Above section in subtle way tries to talk about multiple BFD session 
between same pair but again we need to be clear on what is the motivation?

[XM]  As said above, I tend to believe BFD sessions should be originated and 
terminated at VAP, and usually one NVE owns multiple VAPs. In addition, I 
believe the recent discussion over draft-ietf-bfd-vxlan clarifies much of the 
things in this draft too. 




These are my initial thoughts and would like to see good discussion over this 
draft. Please do let me know if you think we need to address them. 

[XM] Thanks again for your good thoughts. I agree that we need to address them, 
in one way or another.




Thanks
Santosh P K 










Best Regards,

Xiao Min___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3