[bess] Some question about the evpn yang

[Wanghaibo (Rainsword)]

Dear Editors of the EVPN YANG data model draft,


1. I have found that there are list ip-prefix-route under the 
evpn-instance, when will use this?
  +--rw evpn-instances
 +--rw evpn-instance* [name]

+--ro routes

|  +--ro ip-prefix-route*

2. According to this model, how to support EVPN vlan-aware service?


would highly appreciated your responses.

Regards,
Haibo

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Jeffrey,
thank you for the review, detailed questions and helpful comments. Please
find my notes, answers in-line tagged GIM>>.

Regards,
Greg

On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi,
>
>
>
> I have the following questions/comments:
>
>
>
>The procedure described here is an OPTIONAL procedure that consists
>
>of having a downstream PE take into account the status of P-tunnels
>
>rooted at each possible upstream PEs, for including or not including
>
>each given PE in the list of candidate UMHs for a given (C-S,C-G)
>
>state.  The result is that, if a P-tunnel is "down" (see
>
>Section 3.1), the PE that is the root of the P-tunnel will not be
>
>considered for UMH selection, which will result in the downstream PE
>
>to failover to the upstream PE which is next in the list of
>
>candidates.
>
>
>
> Is it possible that a p2mp tunnel is considered up by some leaves but down
> by some other leaves, leaving to them choosing different UMH? In that case,
> procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE")
> of RFC 6513 must be used. I see that this is actually pointed out later in
> section 6 – good to have a pointer to it right here.
>
GIM>> Would the following new text that follows the quoted text address
your concern:
NEW TEXT:
   If rules to determine the state of the P-tunnel are not
   consistent across all PEs, then some may arrive at a different
   conclusion regarding the state of the tunnel, In such a scenario,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used.

>
>
> Additionally, the text in section 3 seems to be more biased on Single
> Forwarder Election choosing the UMH with the highest IP address. Section 5
> of RFC6513 also describes two other options, hashing or based on “installed
> UMH route” (aka unicast-based). It is not clear how the text in this
> document applies to hashing based selection, and I don’t see how the text
> applies to unicast-based selection. Some rewording/clarification are needed
> here.
>
GIM>> How would the use of an alternative UMH selection algorithm change
documented use of p2mp BFD? Do you think that if the Upstream PE selected
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself
no longer applicable?

>
>
>For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
>
>considered up if one or more of the P2MP RSVP-TE LSPs, identified by
>
>the P-tunnel Attribute, are in Up state.
>
>
>
> Why is “one or more of …” used in the above text?
>
GIM>> Would s/one or more of/at least one of/ address your concern?

>
>
> There are several occurrences of ((S, G)). I assume they should be changed
> to (C-S, C-G).
>
GIM>> Indeed, globally replaced s/((S,G))/(C-S,C-G)/

>
>
>A PE can be removed from the UMH candidate list for a given ((S, G))
>
>if the P-tunnel for this (S, G) (I or S , depending) is leaf
>
>triggered (PIM, mLDP)
>
>
>
> Perhaps either remove the (I or S , depending)or move it to before the
> “for”.
>
GIM>> Moved before the "for".

>
>
>This document defines the format and ways of usingr a new BGP
>
>attribute called the "BGP- BFD attribute".
>
>
>
> s/usingr/using/
>
GIM>> Yes, great catch.

>
>
>o  MUST use [Ed.note] address as destination IP address when
>
>   transmitting BFD control packets;
>
>
>
> [Ed.note]?
>
GIM>> Replaced [Ed.note] to make it as follows:
o  MUST use address in 127.0.0.0/8 range for IPv4 or in
  0:0:0:0:0::7F00:0/104 range for IPv6 as destination IP address
  when transmitting BFD control packets;

>
>
>If tracking of the P-tunnel by using a p2mp BFD session is to be
>
>enabled after the P-tunnel has been already signaled, the the
>
>procedure described above MUST be followed.
>
>
>
> What if the tracking is to be enabled before the P-tunnel has been
> signaled? The text implies different behavior?
>
GIM>> Not really, I guess. I think that the second sentence is important:
   Note that x-PMSI A-D Route MUST be re-sent with exactly the same
attributes as before and
   the BGP-BFD Attribute included.

> s/the the/then the/
>
GIM>> Done.

>
>
>… The dedicated p2mp BFD session MAY monitor the state of
>
>the Standby Upstream PE.
>
>
>
> What does the above text mean? Do you mean “A different p2mp BFD session
> …”?
>
GIM>> Yes, thank you for the suggested re-wording. Applied s/The
dedicated/A different/

>
>
>When such a procedure is used, in the context where fast restoration
>
>mechanisms are used for the P-tunnels, leaf PEs should be configured
>
>to wait before updating the UMH, to let the P-tunnel restoration
>
>mechanism happen.  A configurable timer MUST be provided for this
>
>purpose, and it is recommended to provide a reasonable default value
>
>for this timer.
>
>
>
> What does “such a procedure” refers to?
>
GIM>> Would s/When such a procedure is used/In such a scenario/

> 

[bess] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-bess-evpn-virtual-eth-segment

[IETF Secretariat]

Dear Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan:


An IPR disclosure that pertains to your Internet-Draft entitled "EVPN
Virtual Ethernet Segment" (draft-ietf-bess-evpn-virtual-eth-segment) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3354/). The title of the IPR disclosure is
"Cisco's Statement about IPR related to
draft-ietf-bess-evpn-virtual-eth-segment"


Thank you

IETF Secretariat

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

[bess] IPR Disclosure Cisco's Statement about IPR related to draft-ietf-bess-evpn-virtual-eth-segment

[IETF Secretariat]

Dear Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan:


An IPR disclosure that pertains to your Internet-Draft entitled "EVPN
Virtual Ethernet Segment" (draft-ietf-bess-evpn-virtual-eth-segment) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3353/). The title of the IPR disclosure is
"Cisco's Statement about IPR related to
draft-ietf-bess-evpn-virtual-eth-segment"


Thank you

IETF Secretariat

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

[bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding

[IETF Secretariat]

Dear Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan:


An IPR disclosure that pertains to your Internet-Draft entitled
"Integrated Routing and Bridging in EVPN"
(draft-ietf-bess-evpn-inter-subnet-forwarding) was submitted to the IETF
Secretariat on  and has been posted on the "IETF Page of Intellectual
Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3352/). The
title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement
about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding"


Thank you

IETF Secretariat

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

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

It’s an important document. I support its publication as coauthor. Not aware of 
any IPR. Nokia has an implementation for a while now.
Thanks,
Jorge



From: BESS  on behalf of stephane.litkow...@orange.com
Sent: Monday, December 3, 2018 14:43
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_

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] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[John E Drake]

Support, Juniper has supported this feature for an eternity, not aware of any 
IPR

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 3, 2018 5:43 AM
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_



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-liu-bess-mvpn-yang-07

[Xiejingrong]

I support the adoption.

Thanks,
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Monday, December 03, 2018 10:53 PM
To: bess@ietf.org
Cc: draft-liu-bess-mvpn-y...@ietf.org
Subject: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

This email begins a two-week poll for adoption of 
draft-liu-bess-mvpn-yang-07.txt

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 is one IPR declaration 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 Monday 17th December 2018.

Regards,
Matthew


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