Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Gyan Mishra]

Hi Robert

in-line responses

Thank you

Gyan

On Thu, Oct 3, 2019 at 7:29 PM Robert Raszuk  wrote:

> Hello Gyan,
>
> I have read your comment few times. but can't parse it.
>

OK  let me try to clarify

>
> Is this a question ? A concern ? Just comment ?
>
>
Question & Comment I guess let me try and rephrase


> You say:
>
> "Is that true and if so that is a major design concern for migration of
> customers to a SRv6 core."
>
> But what is that ? I am very happy to answer any questions you may have in
> honest way, but just need to understand what the question really is.
>
> So "that" is the BGP services provided by an SRv6 service provider
that if AFI/SAFI  does not change for L3 VPN services and any underlying L3
protocols do not change then it does make SRv6 more viable without major
code rewriting and I believe that is what the purpose of this draft that it
is stating that the overlay services edges at the PE edge weather its L3
VPN vpnv4/vpnv6 6PE/6VPE, MVPN, EVPN whatever that service maybe all of
that will still work but now its just the flow is encapsulated in IPv6 SRv6
EH SRH header inserted by the source node and SID's copied hop by hop to
the destination for the hop by hop Ti-LFA traffic engineered path over the
service provider core.

In the draft I am talking about sections 3.1-vpnv4,3.2 vpnv6 ,3.3 ipv4,3.4
ipv6 4. evpn - that their AFI/SAFI remain the unchanged and will continue
to work as they do today providing seamless migration with what I said
swapping out the "topmost label" which is in MPLS terms but in the SRv6
world  instead of having an MPLS LDP shim now you have IPv6 encapsulation
of the L3 vpn services label using either RFC 4797 or RFC 7510 or new EH
encoding method.

So this is really the crux of it and critical for SRv6 to gain traction and
get of the ground  is having consensus on this draft as BESS WG is
providing the framework for existing technologies AFI/SAFI bgp "services"
to be used over SRv6.  So not having to reinvent the wheel and create a
request for IANA for any new AFI/SAFI for SRv6 as the existing address
families can all be "reused" with SRv6.  The main thing is figuring out
what encapsulation method to use for the L3 VPN label.

Regarding the L3 VPN service label and how that would get encapsulated in
SRv6 you mentioned existing methods using GRE/MPLS RFC 4797 or UDP/MPLS RFC
7510 or a new encoding of VPN label into SRH.  In the draft are you keeping
both options open for the operator to make a decision based on many factors
whichever works best for their environment?  With the later option encoing
VPN label into SRH would you save on overhead bytes from the encapsulation
I am guessing.  What is the benefit of one over the other.  Also when
encapsulating the L3 VPN service label traditionally in an MPLS
environement you only have the VPN label 4 byte shim added to the bottom of
the label stack but now with RFC 4797 with GRE you add extra 24 GRE/IP
bytes and with UDP/MPLS 8 bytes.


> Thx,
> R.
>
> On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra  wrote:
>
>>
>> Hi Robert
>>
>> In-line question
>>
>> Sent from my iPhone
>>
>> On Oct 3, 2019, at 11:01 AM, Robert Raszuk  wrote:
>>
>> Hi Linda,
>>
>> Nope. Nodes except egress have any reason to look at VPN label. That
>> label has only local significance on egress.
>>
>> Thx,
>> R.
>>
>>
>> Robert
>>
>> From an operator perspective ease of implementation and migration is
>> critical to deployment.
>>
>> So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap
>> of the “topmost label” in the label stack and all VPN services label at the
>> bottom of the stack remain unchanged.  Drawing an analogy to SRv6 scenario
>> that would it be exactly the same it sounds like that L3 VPN vpn label
>> remains intact for vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6
>> encapsulation IP/MPLS remains the same no change and it’s just the
>> “topmost” label gets swapped out from either legacy mpls LDP/TE to either
>> SR-MPLS or now SRv6 topmost label. The services bottom label are only
>> imposed by ingress PE as with legacy mpls and per SRv6 End SID programming
>> is either PSP or USP popped similar to legacy mpls PHP UHP and VPN label is
>> then processed by the egress PE identical to how it’s done with SR-MPLS or
>> legacy mpls.
>>
>> So from an operator perspective such as Verizon that does make it
>> attractive and an easy swap out migration or new green field implementation
>> to migrate to SRv6 as all the customer Edge PE-CE protocols and
>> encapsulation VPN related services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan
>> e-line does not change for any services bottom labels.
>>
>> Is that true and if so that is a major design concern for migration of
>> customers to a SRv6 core.
>>
>> With SR-TE now we would have native TE capabilities with SRv6 over
>> SR-MPLS so that we can individually color each per vpn  flow to an SR-TE
>> tunnel over SRv6 core.  I am stating that correctly that is the major

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Patrice Brissette (pbrisset)]

Hi Jorge,


As I mentioned, the draft is actually pretty thin as stated in section 4.2: 
This document enhances the EVPN MAC Duplication Mechanism by extending it with 
an optional Loop-protection action that is applied on the duplicate-MAC 
addresses.

The document describes at glance the problem. I agree that the problem is real 
and must be fixed.
However, the extension is simply an action on the MAC duplication mechanism to 
install a blackhole MAC as an option.
I’m not sure why there is a need for a draft. The action can be vendor 
specific. The fact that the draft is informal makes more sense. However, there 
is a requirement section with *MUST* keywords…. I’m confuse about this…since it 
is informal.

IMO, I would rather add a text to RFC7432bis to suggest what can be done. That 
will highlight the importance of such problem.

Having too many draft dilute the strength of our work.
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Thursday, October 3, 2019 at 08:37
To: Patrice Brissette , Stephane Litkowski 
, "stephane.litkow...@orange.com" 

Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi Patrice,

I understand that you may not support the draft.
However, it would help if you clarify the reason why:


-Is it because you don’t think loops should be protected in the way the 
draft describes? If so please elaborate.

-Or is it that you do support the idea in the draft, but think that it does 
not deserves its own document

-Or maybe none of them? :-)

I think it is important to clarify that on the list.

Thank you.
Jorge


From: "Patrice Brissette (pbrisset)" 
Date: Thursday, October 3, 2019 at 2:25 PM
To: Stephane Litkowski , 
"stephane.litkow...@orange.com" 
Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect
Resent-From: 
Resent-To: , , 
, , 

Resent-Date: Thursday, October 3, 2019 at 2:24 PM

Hi,

I do not support that draft. I think it is a very tiny minor update which can 
incorporated in RFC7432bis.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: BESS  on behalf of Stephane Litkowski 

Date: Thursday, September 19, 2019 at 05:05
To: "stephane.litkow...@orange.com" 
Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Hello Gyan,

I have read your comment few times. but can't parse it.

Is this a question ? A concern ? Just comment ?

You say:

"Is that true and if so that is a major design concern for migration of
customers to a SRv6 core."

But what is that ? I am very happy to answer any questions you may have in
honest way, but just need to understand what the question really is.

Thx,
R.

On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra  wrote:

>
> Hi Robert
>
> In-line question
>
> Sent from my iPhone
>
> On Oct 3, 2019, at 11:01 AM, Robert Raszuk  wrote:
>
> Hi Linda,
>
> Nope. Nodes except egress have any reason to look at VPN label. That label
> has only local significance on egress.
>
> Thx,
> R.
>
>
> Robert
>
> From an operator perspective ease of implementation and migration is
> critical to deployment.
>
> So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap
> of the “topmost label” in the label stack and all VPN services label at the
> bottom of the stack remain unchanged.  Drawing an analogy to SRv6 scenario
> that would it be exactly the same it sounds like that L3 VPN vpn label
> remains intact for vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6
> encapsulation IP/MPLS remains the same no change and it’s just the
> “topmost” label gets swapped out from either legacy mpls LDP/TE to either
> SR-MPLS or now SRv6 topmost label. The services bottom label are only
> imposed by ingress PE as with legacy mpls and per SRv6 End SID programming
> is either PSP or USP popped similar to legacy mpls PHP UHP and VPN label is
> then processed by the egress PE identical to how it’s done with SR-MPLS or
> legacy mpls.
>
> So from an operator perspective such as Verizon that does make it
> attractive and an easy swap out migration or new green field implementation
> to migrate to SRv6 as all the customer Edge PE-CE protocols and
> encapsulation VPN related services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan
> e-line does not change for any services bottom labels.
>
> Is that true and if so that is a major design concern for migration of
> customers to a SRv6 core.
>
> With SR-TE now we would have native TE capabilities with SRv6 over SR-MPLS
> so that we can individually color each per vpn  flow to an SR-TE tunnel
> over SRv6 core.  I am stating that correctly that is the major benefit of
> SRv6 over SR-MPLS.
>
> Gyan
> Verizon Communications
> Cell phone 301 502-1347
>
>
> On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar 
> wrote:
>
>> Robert,
>>
>>
>>
>> Thank you very much for the explanation.
>>
>> With the L3VPN case,  there are nodes between Egress and Ingress PEs that
>> do look into the VPN label carried by the packets for VRF & IP lookup,
>> correct?
>>
>> I was just confused of the statement about “all nodes between Egress &
>> Ingress PE are SR unaware plain IP forwarding nodes”.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Linda
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Thursday, October 03, 2019 3:50 AM
>> *To:* Linda Dunbar 
>> *Cc:* draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
>> *Subject:* Re: [bess] WG adoption and IPR poll for
>> draft-dawra-bess-srv6-services-02
>>
>>
>>
>> Linda,
>>
>>
>>
>> SRv6 services is just a general term used here. Imagine one of such
>> service is L3VPN. VPN label (or pointer to it) is needed to be carried
>> somewhere in the packet as address space may be overlapping between VPN
>> customers and simple IP lookup will not be sufficient to determine VRF or
>> exit interface.
>>
>>
>>
>> One option which has been done and deployed is to encode it natively in
>> the packet and on ingress simply apply prodecures of IPv4 or IPv6
>> encapsulation - RFC4797 and RFC7510
>>
>>
>>
>> The other new option is to take the VPN label or VPN demux value and
>> encode it in SRH or in DO.
>>
>>
>>
>> Now which option to choose is left for the operator to decide likely
>> depending on a lot of other factors involved.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
>> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
>> wrote:
>>
>> I support WG adoption of the draft, with the following questions. Hope
>> authors can help to explain:
>>
>>
>>
>> Section 1 Introduction states that the underlay between the Ingress and
>> Egress only needs to support plain IPv6
>>
>> Forwarding. Those plain IPv6 routers don't need to understand the SR
>> policies encoded in the payload, correct?
>>
>> Why need Ingress PE to encapsulate the policy sent by egress PE if all
>> the nodes between them are plain IPv6 routers?
>>
>>
>>
>> Which PE is to enforce the SR policy?
>>
>> If the policies are for the egress to enforce, why can't the egress PE
>> simply enforce the policy instead of asking ingress node to encapsulate the
>> policy in the packet header? Which has the drawback of extra header bits in
>> packets.
>>
>>
>>
>> Linda Dunbar
>>
>>
>>
>>
>>
>> *From: *"Bocci, Matthew (Nokia - GB)" 
>> *Date: *Friday, September 27, 2019 at 4:00 AM
>> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
>> 

Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Gyan Mishra]

Hi Robert 

In-line question

Sent from my iPhone

> On Oct 3, 2019, at 11:01 AM, Robert Raszuk  wrote:
> 
> Hi Linda, 
> 
> Nope. Nodes except egress have any reason to look at VPN label. That label 
> has only local significance on egress. 
> 
> Thx,
> R.

Robert 

From an operator perspective ease of implementation and migration is critical 
to deployment.

So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap of 
the “topmost label” in the label stack and all VPN services label at the bottom 
of the stack remain unchanged.  Drawing an analogy to SRv6 scenario that would 
it be exactly the same it sounds like that L3 VPN vpn label remains intact for 
vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6 encapsulation IP/MPLS 
remains the same no change and it’s just the “topmost” label gets swapped out 
from either legacy mpls LDP/TE to either SR-MPLS or now SRv6 topmost label. The 
services bottom label are only imposed by ingress PE as with legacy mpls and 
per SRv6 End SID programming is either PSP or USP popped similar to legacy mpls 
PHP UHP and VPN label is then processed by the egress PE identical to how it’s 
done with SR-MPLS or legacy mpls.

So from an operator perspective such as Verizon that does make it attractive 
and an easy swap out migration or new green field implementation to migrate to 
SRv6 as all the customer Edge PE-CE protocols and encapsulation VPN related 
services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan e-line does not change for any 
services bottom labels.

Is that true and if so that is a major design concern for migration of 
customers to a SRv6 core.

With SR-TE now we would have native TE capabilities with SRv6 over SR-MPLS so 
that we can individually color each per vpn  flow to an SR-TE tunnel over SRv6 
core.  I am stating that correctly that is the major benefit of SRv6 over 
SR-MPLS.

Gyan
Verizon Communications 
Cell phone 301 502-1347
> 
>> On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar  
>> wrote:
>> Robert,
>> 
>>  
>> 
>> Thank you very much for the explanation.
>> 
>> With the L3VPN case,  there are nodes between Egress and Ingress PEs that do 
>> look into the VPN label carried by the packets for VRF & IP lookup, correct? 
>>  
>> 
>> I was just confused of the statement about “all nodes between Egress & 
>> Ingress PE are SR unaware plain IP forwarding nodes”.
>> 
>>  
>> 
>> Thanks,
>> 
>>  
>> 
>> Linda
>> 
>>  
>> 
>> From: Robert Raszuk  
>> Sent: Thursday, October 03, 2019 3:50 AM
>> To: Linda Dunbar 
>> Cc: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
>> Subject: Re: [bess] WG adoption and IPR poll for 
>> draft-dawra-bess-srv6-services-02
>> 
>>  
>> 
>> Linda,
>> 
>>  
>> 
>> SRv6 services is just a general term used here. Imagine one of such service 
>> is L3VPN. VPN label (or pointer to it) is needed to be carried somewhere in 
>> the packet as address space may be overlapping between VPN customers and 
>> simple IP lookup will not be sufficient to determine VRF or exit interface. 
>> 
>>  
>> 
>> One option which has been done and deployed is to encode it natively in the 
>> packet and on ingress simply apply prodecures of IPv4 or IPv6 encapsulation 
>> - RFC4797 and RFC7510
>> 
>>  
>> 
>> The other new option is to take the VPN label or VPN demux value and encode 
>> it in SRH or in DO. 
>> 
>>  
>> 
>> Now which option to choose is left for the operator to decide likely 
>> depending on a lot of other factors involved. 
>> 
>>  
>> 
>> Thx,
>> 
>> R.
>> 
>>  
>> 
>> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar  
>> wrote:
>> 
>> I support WG adoption of the draft, with the following questions. Hope 
>> authors can help to explain:
>> 
>>  
>> 
>> Section 1 Introduction states that the underlay between the Ingress and 
>> Egress only needs to support plain IPv6
>> 
>> Forwarding. Those plain IPv6 routers don't need to understand the SR 
>> policies encoded in the payload, correct?
>> 
>> Why need Ingress PE to encapsulate the policy sent by egress PE if all the 
>> nodes between them are plain IPv6 routers?  
>> 
>>  
>> 
>> Which PE is to enforce the SR policy?
>> 
>> If the policies are for the egress to enforce, why can't the egress PE 
>> simply enforce the policy instead of asking ingress node to encapsulate the 
>> policy in the packet header? Which has the drawback of extra header bits in 
>> packets.
>> 
>>  
>> 
>> Linda Dunbar
>> 
>>  
>> 
>>  
>> 
>> From: "Bocci, Matthew (Nokia - GB)" 
>> Date: Friday, September 27, 2019 at 4:00 AM
>> To: "draft-dawra-bess-srv6-servi...@ietf.org" 
>> , "bess@ietf.org" 
>> Subject: WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 
>> Resent-From: 
>> Resent-To: , , 
>> , Swadesh Agrawal , 
>> , , , 
>> , , 
>> , , 
>> 
>> Resent-Date: Friday, September 27, 2019 at 4:00 AM
>> 
>>  
>> 
>> Hello,
>> 
>>  
>> 
>> This email begins a two-weeks WG adoption poll for 
>> draft-dawra-bess-srv6-services-02 [1] .
>> 
>>  
>> 
>> Please review the draft and post any 

Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Hi Linda,

Nope. Nodes except egress have any reason to look at VPN label. That label
has only local significance on egress.

Thx,
R.

On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the explanation.
>
> With the L3VPN case,  there are nodes between Egress and Ingress PEs that
> do look into the VPN label carried by the packets for VRF & IP lookup,
> correct?
>
> I was just confused of the statement about “all nodes between Egress &
> Ingress PE are SR unaware plain IP forwarding nodes”.
>
>
>
> Thanks,
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Thursday, October 03, 2019 3:50 AM
> *To:* Linda Dunbar 
> *Cc:* draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
> *Subject:* Re: [bess] WG adoption and IPR poll for
> draft-dawra-bess-srv6-services-02
>
>
>
> Linda,
>
>
>
> SRv6 services is just a general term used here. Imagine one of such
> service is L3VPN. VPN label (or pointer to it) is needed to be carried
> somewhere in the packet as address space may be overlapping between VPN
> customers and simple IP lookup will not be sufficient to determine VRF or
> exit interface.
>
>
>
> One option which has been done and deployed is to encode it natively in
> the packet and on ingress simply apply prodecures of IPv4 or IPv6
> encapsulation - RFC4797 and RFC7510
>
>
>
> The other new option is to take the VPN label or VPN demux value and
> encode it in SRH or in DO.
>
>
>
> Now which option to choose is left for the operator to decide likely
> depending on a lot of other factors involved.
>
>
>
> Thx,
>
> R.
>
>
>
> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
> wrote:
>
> I support WG adoption of the draft, with the following questions. Hope
> authors can help to explain:
>
>
>
> Section 1 Introduction states that the underlay between the Ingress and
> Egress only needs to support plain IPv6
>
> Forwarding. Those plain IPv6 routers don't need to understand the SR
> policies encoded in the payload, correct?
>
> Why need Ingress PE to encapsulate the policy sent by egress PE if all the
> nodes between them are plain IPv6 routers?
>
>
>
> Which PE is to enforce the SR policy?
>
> If the policies are for the egress to enforce, why can't the egress PE
> simply enforce the policy instead of asking ingress node to encapsulate the
> policy in the packet header? Which has the drawback of extra header bits in
> packets.
>
>
>
> Linda Dunbar
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
> *Date: *Friday, September 27, 2019 at 4:00 AM
> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" 
> *Subject: *WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
> *Resent-From: *
> *Resent-To: *, , <
> pbris...@cisco.com>, Swadesh Agrawal , <
> daniel.vo...@bell.ca>, , , <
> rob...@raszuk.net>, , <
> satoru.matsush...@g.softbank.co.jp>, , <
> jorge.raba...@nokia.com>
> *Resent-Date: *Friday, September 27, 2019 at 4:00 AM
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
> 
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Questions to draft-dawra-bess-srv6-services-02

[Linda Dunbar]

Robert,

Thank you very much for the explanation.
With the L3VPN case,  there are nodes between Egress and Ingress PEs that do 
look into the VPN label carried by the packets for VRF & IP lookup, correct?
I was just confused of the statement about “all nodes between Egress & Ingress 
PE are SR unaware plain IP forwarding nodes”.

Thanks,

Linda

From: Robert Raszuk 
Sent: Thursday, October 03, 2019 3:50 AM
To: Linda Dunbar 
Cc: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-dawra-bess-srv6-services-02

Linda,

SRv6 services is just a general term used here. Imagine one of such service is 
L3VPN. VPN label (or pointer to it) is needed to be carried somewhere in the 
packet as address space may be overlapping between VPN customers and simple IP 
lookup will not be sufficient to determine VRF or exit interface.

One option which has been done and deployed is to encode it natively in the 
packet and on ingress simply apply prodecures of IPv4 or IPv6 encapsulation - 
RFC4797 and RFC7510

The other new option is to take the VPN label or VPN demux value and encode it 
in SRH or in DO.

Now which option to choose is left for the operator to decide likely depending 
on a lot of other factors involved.

Thx,
R.

On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
I support WG adoption of the draft, with the following questions. Hope authors 
can help to explain:

Section 1 Introduction states that the underlay between the Ingress and Egress 
only needs to support plain IPv6
Forwarding. Those plain IPv6 routers don't need to understand the SR policies 
encoded in the payload, correct?
Why need Ingress PE to encapsulate the policy sent by egress PE if all the 
nodes between them are plain IPv6 routers?

Which PE is to enforce the SR policy?
If the policies are for the egress to enforce, why can't the egress PE simply 
enforce the policy instead of asking ingress node to encapsulate the policy in 
the packet header? Which has the drawback of extra header bits in packets.

Linda Dunbar


From: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Friday, September 27, 2019 at 4:00 AM
To: 
"draft-dawra-bess-srv6-servi...@ietf.org"
 
mailto:draft-dawra-bess-srv6-servi...@ietf.org>>,
 "bess@ietf.org" mailto:bess@ietf.org>>
Subject: WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:gdawra.i...@gmail.com>>, 
mailto:cfils...@cisco.com>>, 
mailto:pbris...@cisco.com>>, Swadesh Agrawal 
mailto:swaag...@cisco.com>>, 
mailto:daniel.vo...@bell.ca>>, 
mailto:daniel.bern...@bell.ca>>, 
mailto:d...@steinberg.net>>, 
mailto:rob...@raszuk.net>>, 
mailto:bruno.decra...@orange.com>>, 
mailto:satoru.matsush...@g.softbank.co.jp>>,
 mailto:zhuangshun...@huawei.com>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Friday, September 27, 2019 at 4:00 AM

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

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

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[slitkows.ietf]

Hi all,

 

This adoption call is running for a long time. The WG adoption was a bit tough 
or at least unusual.

 

I hold on this call waiting for a sync-up with my co-chair to decide how we 
proceed.

 

We keep you posted asap.

 

Stephane

 

 

From: Rabadan, Jorge (Nokia - US/Mountain View)  
Sent: jeudi 3 octobre 2019 00:51
To: Ali Sajassi (sajassi) ; stephane.litkow...@orange.com; 
bess@ietf.org; draft-snr-bess-evpn-loop-prot...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

 

Hi Ali,

 

Thank you for your feedback.

 

The draft is going through a WG adoption call, and although during the first 
part of the adoption call there was not much feedback, the draft has now fair 
good support from several Service Providers and vendors. We also got the 
feedback from a Service Provider that the topic is important enough to deserve 
a separate document where the WG can throw feedback and can be improved to make 
sure all cases are covered. So I believe it has to be adopted as an 
(Informational) WG document. 

 

When 7432bis is WG adopted (it’s not even published yet!), as a WG we can 
decide if loop-protection is part of it or not. My co-authors, other WG members 
and chairs can express their opinion as well.

 

About backhole mac vs ACL – backhole is more generic. You can implement it via 
ACL or flags in the bridge table or any other way. We don’t mandate how to do 
it, only the required behavior. If you do it via an “automatic” ACL, that’s 
your implementation choice. 

 

About the timer, it would be good if you can elaborate why it is questionable. 
We are very interested in your feedback and we would like to encourage the WG 
to also participate in the discussion, if the WG thinks loops are an important 
topic.

 

Thanks.

Jorge

 

 

From: "Ali Sajassi (sajassi)" mailto:saja...@cisco.com> >
Date: Thursday, October 3, 2019 at 8:17 AM
To: "stephane.litkow...@orange.com  " 
mailto:stephane.litkow...@orange.com> >, 
"bess@ietf.org  " mailto:bess@ietf.org> 
>, "draft-snr-bess-evpn-loop-prot...@ietf.org 
 " 
mailto:draft-snr-bess-evpn-loop-prot...@ietf.org> >
Cc: "bess-cha...@ietf.org  " mailto:bess-cha...@ietf.org> >
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect
Resent-From: mailto:alias-boun...@ietf.org> >
Resent-To: mailto:jorge.raba...@nokia.com> >, 
mailto:senthil.sathap...@nokia.com> >, 
mailto:kiran.naga...@nokia.com> >, 
mailto:julio.buenohernan...@telefonica.com> >, 
mailto:josemanuel.crespogar...@telefonica.com> >
Resent-Date: Thursday, October 3, 2019 at 8:17 AM

 

 

We need to cover the loop protection for EVPN as we needed to cover MAC 
duplicate detection in EVPN. However, I am wondering why not simply cover it in 
couple of paragraphs in RFC7432bis. I made this comment when this draft was 
presented for the first time. My rational for it is as follow:

 

1)  The detection mechanism for loop protection is identical to MAC 
duplicate detection as described in section 15.1 of RFC 7432. As the matter of 
fact the procedure described in section 15.1 of RFC 7432 is repeated in this 
new draft.

2)  The only difference is action taken. For MAC duplicate detection, we 
stop advertising the learned MAC address; whereas, for loop prevention, we 
install an ACL for the duplicate MAC.

3)  We should also try to use commonly used terms as opposed to inventing 
new terms – i.e., instead of creating a new section in describing what 
blackhole MAC is, we should simply say we want to install ACL for MAC SA (to 
get discarded). 

4)  The new timer for flushing MAC SA and restarting the process IMO is 
questionable and should not be used.

 

Again, if we were not doing RFC7432bis, I would have been very supportive of 
this draft as we do need to cover loop protection; however, given that we can 
cover this loop protection by just adding one or two paragraphs to section 
15.1, then I really don’t see the need to create unnecessary reading materials 
for our community.

 

Cheers,

Ali

 

 

 

From: BESS mailto:bess-boun...@ietf.org> > on behalf of 
"stephane.litkow...@orange.com  " 
mailto:stephane.litkow...@orange.com> >
Date: Monday, September 2, 2019 at 7:29 AM
To: "bess@ietf.org  " mailto:bess@ietf.org> >, "draft-snr-bess-evpn-loop-prot...@ietf.org 
 " 
mailto:draft-snr-bess-evpn-loop-prot...@ietf.org> >
Cc: "bess-cha...@ietf.org  " mailto:bess-cha...@ietf.org> >
Subject: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

 

Hi,

 

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]

Please review the draft and post any 

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

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

Hi Patrice,

I understand that you may not support the draft.
However, it would help if you clarify the reason why:


  *   Is it because you don’t think loops should be protected in the way the 
draft describes? If so please elaborate.
  *   Or is it that you do support the idea in the draft, but think that it 
does not deserves its own document
  *   Or maybe none of them? :-)

I think it is important to clarify that on the list.

Thank you.
Jorge


From: "Patrice Brissette (pbrisset)" 
Date: Thursday, October 3, 2019 at 2:25 PM
To: Stephane Litkowski , 
"stephane.litkow...@orange.com" 
Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect
Resent-From: 
Resent-To: , , 
, , 

Resent-Date: Thursday, October 3, 2019 at 2:24 PM

Hi,

I do not support that draft. I think it is a very tiny minor update which can 
incorporated in RFC7432bis.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: BESS  on behalf of Stephane Litkowski 

Date: Thursday, September 19, 2019 at 05:05
To: "stephane.litkow...@orange.com" 
Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Patrice Brissette (pbrisset)]

As co-author, I support this draft.
I’m not aware of any other IPR.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Bocci, Matthew (Nokia - GB)" 
Date: Friday, September 27, 2019 at 06:59
To: "draft-dawra-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
Resent-From: 
Resent-To: , , Patrice Brissette 
, , , 
, , , 
, , 
, 
Resent-Date: Friday, September 27, 2019 at 07:00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

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

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Linda,

SRv6 services is just a general term used here. Imagine one of such
service is L3VPN. VPN label (or pointer to it) is needed to be carried
somewhere in the packet as address space may be overlapping between VPN
customers and simple IP lookup will not be sufficient to determine VRF or
exit interface.

One option which has been done and deployed is to encode it natively in the
packet and on ingress simply apply prodecures of IPv4 or IPv6 encapsulation
- RFC4797 and RFC7510

The other new option is to take the VPN label or VPN demux value and encode
it in SRH or in DO.

Now which option to choose is left for the operator to decide likely
depending on a lot of other factors involved.

Thx,
R.

On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
wrote:

> I support WG adoption of the draft, with the following questions. Hope
> authors can help to explain:
>
>
>
> Section 1 Introduction states that the underlay between the Ingress and
> Egress only needs to support plain IPv6
>
> Forwarding. Those plain IPv6 routers don't need to understand the SR
> policies encoded in the payload, correct?
>
> Why need Ingress PE to encapsulate the policy sent by egress PE if all the
> nodes between them are plain IPv6 routers?
>
>
>
> Which PE is to enforce the SR policy?
>
> If the policies are for the egress to enforce, why can't the egress PE
> simply enforce the policy instead of asking ingress node to encapsulate the
> policy in the packet header? Which has the drawback of extra header bits in
> packets.
>
>
>
> Linda Dunbar
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
> *Date: *Friday, September 27, 2019 at 4:00 AM
> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" 
> *Subject: *WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
> *Resent-From: *
> *Resent-To: *, , <
> pbris...@cisco.com>, Swadesh Agrawal , <
> daniel.vo...@bell.ca>, , , <
> rob...@raszuk.net>, , <
> satoru.matsush...@g.softbank.co.jp>, , <
> jorge.raba...@nokia.com>
> *Resent-Date: *Friday, September 27, 2019 at 4:00 AM
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
> 
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

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

Hi Ali,

Thank you for your feedback.

The draft is going through a WG adoption call, and although during the first 
part of the adoption call there was not much feedback, the draft has now fair 
good support from several Service Providers and vendors. We also got the 
feedback from a Service Provider that the topic is important enough to deserve 
a separate document where the WG can throw feedback and can be improved to make 
sure all cases are covered. So I believe it has to be adopted as an 
(Informational) WG document.

When 7432bis is WG adopted (it’s not even published yet!), as a WG we can 
decide if loop-protection is part of it or not. My co-authors, other WG members 
and chairs can express their opinion as well.

About backhole mac vs ACL – backhole is more generic. You can implement it via 
ACL or flags in the bridge table or any other way. We don’t mandate how to do 
it, only the required behavior. If you do it via an “automatic” ACL, that’s 
your implementation choice.

About the timer, it would be good if you can elaborate why it is questionable. 
We are very interested in your feedback and we would like to encourage the WG 
to also participate in the discussion, if the WG thinks loops are an important 
topic.

Thanks.
Jorge


From: "Ali Sajassi (sajassi)" 
Date: Thursday, October 3, 2019 at 8:17 AM
To: "stephane.litkow...@orange.com" , 
"bess@ietf.org" , "draft-snr-bess-evpn-loop-prot...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect
Resent-From: 
Resent-To: , , 
, , 

Resent-Date: Thursday, October 3, 2019 at 8:17 AM


We need to cover the loop protection for EVPN as we needed to cover MAC 
duplicate detection in EVPN. However, I am wondering why not simply cover it in 
couple of paragraphs in RFC7432bis. I made this comment when this draft was 
presented for the first time. My rational for it is as follow:


1)  The detection mechanism for loop protection is identical to MAC 
duplicate detection as described in section 15.1 of RFC 7432. As the matter of 
fact the procedure described in section 15.1 of RFC 7432 is repeated in this 
new draft.

2)  The only difference is action taken. For MAC duplicate detection, we 
stop advertising the learned MAC address; whereas, for loop prevention, we 
install an ACL for the duplicate MAC.

3)  We should also try to use commonly used terms as opposed to inventing 
new terms – i.e., instead of creating a new section in describing what 
blackhole MAC is, we should simply say we want to install ACL for MAC SA (to 
get discarded).

4)  The new timer for flushing MAC SA and restarting the process IMO is 
questionable and should not be used.

Again, if we were not doing RFC7432bis, I would have been very supportive of 
this draft as we do need to cover loop protection; however, given that we can 
cover this loop protection by just adding one or two paragraphs to section 
15.1, then I really don’t see the need to create unnecessary reading materials 
for our community.

Cheers,
Ali



From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, September 2, 2019 at 7:29 AM
To: "bess@ietf.org" , 
"draft-snr-bess-evpn-loop-prot...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Mankamana Mishra (mankamis)]

Support the adoption.

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

Date: Friday, September 27, 2019 at 4:01 AM
To: "draft-dawra-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [1] .

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

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Ali Sajassi (sajassi)]

We need to cover the loop protection for EVPN as we needed to cover MAC 
duplicate detection in EVPN. However, I am wondering why not simply cover it in 
couple of paragraphs in RFC7432bis. I made this comment when this draft was 
presented for the first time. My rational for it is as follow:


  1.  The detection mechanism for loop protection is identical to MAC duplicate 
detection as described in section 15.1 of RFC 7432. As the matter of fact the 
procedure described in section 15.1 of RFC 7432 is repeated in this new draft.
  2.  The only difference is action taken. For MAC duplicate detection, we stop 
advertising the learned MAC address; whereas, for loop prevention, we install 
an ACL for the duplicate MAC.
  3.  We should also try to use commonly used terms as opposed to inventing new 
terms – i.e., instead of creating a new section in describing what blackhole 
MAC is, we should simply say we want to install ACL for MAC SA (to get 
discarded).
  4.  The new timer for flushing MAC SA and restarting the process IMO is 
questionable and should not be used.

Again, if we were not doing RFC7432bis, I would have been very supportive of 
this draft as we do need to cover loop protection; however, given that we can 
cover this loop protection by just adding one or two paragraphs to section 
15.1, then I really don’t see the need to create unnecessary reading materials 
for our community.

Cheers,
Ali



From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, September 2, 2019 at 7:29 AM
To: "bess@ietf.org" , 
"draft-snr-bess-evpn-loop-prot...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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