Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support

Regards

Hooman

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, September 24, 2018 11:17 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Subject: Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

I fully support the publication of this document.
It should have been an RFC long time back. I don’t understand why it took so 
long.

Nokia has an implementation of this draft in SROS.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Monday, September 24, 2018 at 1:04 PM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

Please review the draft and post any comments to the BESS working group list.

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



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

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Nabeel Cocker]

Support. 

Regards,
Nabeel

> On Sep 24, 2018, at 11:16 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
>  wrote:
> 
> I fully support the publication of this document.
> It should have been an RFC long time back. I don’t understand why it took so 
> long.
>  
> Nokia has an implementation of this draft in SROS.
>  
> Thanks.
> Jorge
>  
> From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 
> 
> Date: Monday, September 24, 2018 at 1:04 PM
> To: "bess@ietf.org" 
> Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02
>  
> All
>  
> Since we have received a recent IPR declaration on this draft and the first 
> WG last call was so long ago, we are running a second last call to reaffirm 
> WG consensus to publish the draft as an RFC.
>  
> Therefore, this email begins a two-week working group last call for 
> draft-ietf-bess-vpls-multihoming-02.txt
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> Currently there is one IPR declaration against this document.
>  
> We are also polling for any existing implementations.
>  
> The working group last call closes on Monday 8th Oct 2018. 
>  
> Regards,
> Matthew and Stéphane
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On Sep 24, 2018, at 11:21, Henderickx, Wim (Nokia - BE/Antwerp) 
>  wrote:
> 
> Agreed.
>  
> From: BESS  on behalf of Jorge Rabadan 
> 
> Date: Monday, 24 September 2018 at 17:16
> To: "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 
> 
> Subject: Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02
>  
> I fully support the publication of this document.
> It should have been an RFC long time back. I don’t understand why it took so 
> long.
>  
> Nokia has an implementation of this draft in SROS.
>  
> Thanks.
> Jorge
>  
> From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 
> 
> Date: Monday, September 24, 2018 at 1:04 PM
> To: "bess@ietf.org" 
> Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02
>  
> All
>  
> Since we have received a recent IPR declaration on this draft and the first 
> WG last call was so long ago, we are running a second last call to reaffirm 
> WG consensus to publish the draft as an RFC.
>  
> Therefore, this email begins a two-week working group last call for 
> draft-ietf-bess-vpls-multihoming-02.txt
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> Currently there is one IPR declaration against this document.
>  
> We are also polling for any existing implementations.
>  
> The working group last call closes on Monday 8th Oct 2018. 
>  
> Regards,
> Matthew and Stéphane
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Henderickx, Wim (Nokia - BE/Antwerp)]

Agreed.

From: BESS  on behalf of Jorge Rabadan 

Date: Monday, 24 September 2018 at 17:16
To: "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Subject: Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

I fully support the publication of this document.
It should have been an RFC long time back. I don’t understand why it took so 
long.

Nokia has an implementation of this draft in SROS.

Thanks.
Jorge

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, September 24, 2018 at 1:04 PM
To: "bess@ietf.org" 
Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

Please review the draft and post any comments to the BESS working group list.

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



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

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

I fully support the publication of this document.
It should have been an RFC long time back. I don’t understand why it took so 
long.

Nokia has an implementation of this draft in SROS.

Thanks.
Jorge

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, September 24, 2018 at 1:04 PM
To: "bess@ietf.org" 
Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

Please review the draft and post any comments to the BESS working group list.

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



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

[bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Bocci, Matthew (Nokia - GB)]

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

Please review the draft and post any comments to the BESS working group list.

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



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

Re: [bess] EVPN FECs in LSP Ping

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

As Donald has mentioned, 7432 simply left Ethernet service OAM out of scope, so 
there are quite a few things tbat require specification in this area..

Regards



Thumb typed by Sasha Vainshtein


From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Monday, September 24, 2018 12:37:13 PM
To: Alexander Vainshtein; Donald Eastlake
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org; Michael Gorokhovsky; Ron 
Sdayoor; bess@ietf.org; Rotem Cohen
Subject: Re: [bess] EVPN FECs in LSP Ping

Sasha,

That is an excellent point. I agree the text should say that any MEP/MIP MAC 
addresses local to the PE should be advertised in EVPN.
I would even add that, since those MACs are not subject to mobility, the PE 
should advertise them as “static”, i.e., with sticky bit set.

Thanks.
Jorge


From: BESS  on behalf of Alexander Vainshtein 

Date: Monday, September 24, 2018 at 8:13 AM
To: Donald Eastlake 
Cc: "draft-salam-bess-evpn-oam-req-fr...@ietf.org" 
, Michael Gorokhovsky 
, Ron Sdayoor , 
"bess@ietf.org" , Rotem Cohen 
Subject: Re: [bess] EVPN FECs in LSP Ping

Donald,
Lots of thanks again for a primpt response.
Explicitly stafing that an EVPN PE supporting customer level Ethernet service 
OAM MUST adverise locally learned MAC addresses of the customer's MEPS would 
address my concerns.
Regards
Thumb typed by Sasha Vainshtein


From: Donald Eastlake
Sent: Sunday, September 23, 22:34
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, Michael 
Gorokhovsky, Ron Sdayoor, Rotem Cohen

Hi Sasha, On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein wrote: > > 
Donald, > Lots of thanks for your response. > > I would like to clarify my 
question regarding learning of the MAC address of the customer MEP. > > I fully 
agree that this address will be locally learned by the PE to whic the relevant 
customer site is attached. > > But will this address advertised to remote PEs? 
> > My reading of 7432 is that in most cases PEs advertise MAC addresses that 
have been locally learned from some CP protocol; 7432 specifically mentions 
ARP/NDP and DHCP/DHCPv6. > > I think that in order to learn and advertise MAC 
addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM 
frames (trap is required for LTM frames if MIP us intanciated in the PE). > > 
Does this make sense to you? I would agree that a PE has to advertise the MAC 
addresses it learns from the local reception Ethernet Service OAM frames if it 
wants to support that service and it would be reasonable to mention this in the 
EVPN OAM framework document. RFC 7432 was not considering OAM. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards > > 
Thumb typed by Sasha Vainshtein > > From: Donald Eastlake > Sent: Monday, 
September 17, 01:43 > Subject: Re: EVPN FECs in LSP Ping > To: Alexander 
Vainshtein > Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, 
Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen > > Hi Sasha, Thanks for your 
questions. See below. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein 
wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I 
have looked up the draft, and it looks to me as a good starting > point for 
work on EVPN OAM. Thanks. > I would like to clarify two points with regard to 
the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > 
local MAC-VRF must learn the MAC address of the customer MEP and > advertise it 
to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a 
special case of learning from the control > plane (in addition to 
ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of 
the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the 
following text, which seems adequate to me: The PEs in a particular EVPN 
instance MUST support local data-plane learning using standard IEEE Ethernet 
learning procedures. > 2. The draft seems to propose extension of LSP Ping to 
test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I 
have > checked the IANA Registry, and no values for these FECs have been > 
allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism 
indirectly referenced in Section 2..4 of the draft via the reference to RFC 
6425 but there are others. Since OAM messages need to follow the same path as 
data, as far as practical, it seem to me there should not be any FECs allocated 
for OAM beyond those already needed for data. Probably wording in the draft 
related to FECs should be checked/adjusted. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards, > 
Sasha > > 

Re: [bess] EVPN FECs in LSP Ping

[Rabadan, Jorge (Nokia - US/Mountain View)]

Sasha,

That is an excellent point. I agree the text should say that any MEP/MIP MAC 
addresses local to the PE should be advertised in EVPN.
I would even add that, since those MACs are not subject to mobility, the PE 
should advertise them as “static”, i.e., with sticky bit set.

Thanks.
Jorge


From: BESS  on behalf of Alexander Vainshtein 

Date: Monday, September 24, 2018 at 8:13 AM
To: Donald Eastlake 
Cc: "draft-salam-bess-evpn-oam-req-fr...@ietf.org" 
, Michael Gorokhovsky 
, Ron Sdayoor , 
"bess@ietf.org" , Rotem Cohen 
Subject: Re: [bess] EVPN FECs in LSP Ping

Donald,
Lots of thanks again for a primpt response.
Explicitly stafing that an EVPN PE supporting customer level Ethernet service 
OAM MUST adverise locally learned MAC addresses of the customer's MEPS would 
address my concerns.
Regards
Thumb typed by Sasha Vainshtein


From: Donald Eastlake
Sent: Sunday, September 23, 22:34
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, Michael 
Gorokhovsky, Ron Sdayoor, Rotem Cohen

Hi Sasha, On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein wrote: > > 
Donald, > Lots of thanks for your response. > > I would like to clarify my 
question regarding learning of the MAC address of the customer MEP. > > I fully 
agree that this address will be locally learned by the PE to whic the relevant 
customer site is attached. > > But will this address advertised to remote PEs? 
> > My reading of 7432 is that in most cases PEs advertise MAC addresses that 
have been locally learned from some CP protocol; 7432 specifically mentions 
ARP/NDP and DHCP/DHCPv6. > > I think that in order to learn and advertise MAC 
addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM 
frames (trap is required for LTM frames if MIP us intanciated in the PE). > > 
Does this make sense to you? I would agree that a PE has to advertise the MAC 
addresses it learns from the local reception Ethernet Service OAM frames if it 
wants to support that service and it would be reasonable to mention this in the 
EVPN OAM framework document. RFC 7432 was not considering OAM. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards > > 
Thumb typed by Sasha Vainshtein > > From: Donald Eastlake > Sent: Monday, 
September 17, 01:43 > Subject: Re: EVPN FECs in LSP Ping > To: Alexander 
Vainshtein > Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, 
Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen > > Hi Sasha, Thanks for your 
questions. See below. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein 
wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I 
have looked up the draft, and it looks to me as a good starting > point for 
work on EVPN OAM. Thanks. > I would like to clarify two points with regard to 
the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > 
local MAC-VRF must learn the MAC address of the customer MEP and > advertise it 
to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a 
special case of learning from the control > plane (in addition to 
ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of 
the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the 
following text, which seems adequate to me: The PEs in a particular EVPN 
instance MUST support local data-plane learning using standard IEEE Ethernet 
learning procedures. > 2. The draft seems to propose extension of LSP Ping to 
test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I 
have > checked the IANA Registry, and no values for these FECs have been > 
allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism 
indirectly referenced in Section 2..4 of the draft via the reference to RFC 
6425 but there are others. Since OAM messages need to follow the same path as 
data, as far as practical, it seem to me there should not be any FECs allocated 
for OAM beyond those already needed for data. Probably wording in the draft 
related to FECs should be checked/adjusted. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards, > 
Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: 
alexander.vainsht...@ecitele.com

___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

Re: [bess] EVPN FECs in LSP Ping

[Alexander Vainshtein]

Donald,
Lots of thanks again for a primpt response.
Explicitly stafing that an EVPN PE supporting customer level Ethernet service 
OAM MUST adverise locally learned MAC addresses of the customer's MEPS would 
address my concerns.

Regards

Thumb typed by Sasha Vainshtein



From: Donald Eastlake
Sent: Sunday, September 23, 22:34
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, Michael 
Gorokhovsky, Ron Sdayoor, Rotem Cohen


Hi Sasha, On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein wrote: > > 
Donald, > Lots of thanks for your response. > > I would like to clarify my 
question regarding learning of the MAC address of the customer MEP. > > I fully 
agree that this address will be locally learned by the PE to whic the relevant 
customer site is attached. > > But will this address advertised to remote PEs? 
> > My reading of 7432 is that in most cases PEs advertise MAC addresses that 
have been locally learned from some CP protocol; 7432 specifically mentions 
ARP/NDP and DHCP/DHCPv6. > > I think that in order to learn and advertise MAC 
addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM 
frames (trap is required for LTM frames if MIP us intanciated in the PE). > > 
Does this make sense to you? I would agree that a PE has to advertise the MAC 
addresses it learns from the local reception Ethernet Service OAM frames if it 
wants to support that service and it would be reasonable to mention this in the 
EVPN OAM framework document. RFC 7432 was not considering OAM. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards > > 
Thumb typed by Sasha Vainshtein > > From: Donald Eastlake > Sent: Monday, 
September 17, 01:43 > Subject: Re: EVPN FECs in LSP Ping > To: Alexander 
Vainshtein > Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, 
Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen > > Hi Sasha, Thanks for your 
questions. See below.. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein 
wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I 
have looked up the draft, and it looks to me as a good starting > point for 
work on EVPN OAM. Thanks. > I would like to clarify two points with regard to 
the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > 
local MAC-VRF must learn the MAC address of the customer MEP and > advertise it 
to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a 
special case of learning from the control > plane (in addition to 
ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of 
the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the 
following text, which seems adequate to me: The PEs in a particular EVPN 
instance MUST support local data-plane learning using standard IEEE Ethernet 
learning procedures. > 2. The draft seems to propose extension of LSP Ping to 
test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I 
have > checked the IANA Registry, and no values for these FECs have been > 
allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism 
indirectly referenced in Section 2.4 of the draft via the reference to RFC 6425 
but there are others. Since OAM messages need to follow the same path as data, 
as far as practical, it seem to me there should not be any FECs allocated for 
OAM beyond those already needed for data. Probably wording in the draft related 
to FECs should be checked/adjusted. Thanks, Donald 
=== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 
1424 Pro Shop Court, Davenport, FL 33896 USA d3e...@gmail.com > Regards, > 
Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: 
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess