Re: [bess] Questions about the EVPN YANG data model draft

[Alexander Vainshtein]

Patrice,
Lots of thanks for a prompt response.

I have just looked up the diff between -05 and -06 versions of the draft.

It seems that the only change is refresh of references as some of the drafts to 
which the -05 version referred have been publishesd as RFCs.

So I think that my questions equally apply to the -06 version.

Regards,
Sasha

Thumb typed by Sasha Vainshtein


From: Patrice Brissette (pbrisset) 
Sent: Tuesday, October 23, 2018 3:19:28 AM
To: Alexander Vainshtein; hs...@ciena.com; jorge.raba...@nokia.com; 
ing-wher_c...@jabil.com; ihuss...@infinera.com; kisho...@juniper.net
Cc: bess@ietf.org
Subject: Re: Questions about the EVPN YANG data model draft

Hi Alex,

I just refresh the draft. Unfortunately, I just notice your email. I will make 
sure it is properly handle.

Regards,

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



From: Alexander Vainshtein 
Date: Sunday, October 21, 2018 at 7:00 AM
To: Patrice Brissette , "hs...@ciena.com" 
, "jorge.raba...@nokia.com" , 
"ing-wher_c...@jabil.com" , "ihuss...@infinera.com" 
, "kisho...@juniper.net" 
Cc: "bess@ietf.org" 
Subject: Questions about the EVPN YANG data model draft

Dear Editors of the EVPN YANG data model 
draft,
I have several questions regarding the draft, and would highly appreciated your 
responses.


1.   The -05 version of the draft has expired almost two months ago. Do you 
plan to refresh it any time soon?

2.   The draft consistently uses type uint32 for the Ethernet segment 
identifier (ESI), while RFC 7432 explicitly defines it as a 10-octet integer. 
Is this just a typo, or did I miss something substantial here?

3.   The draft states that it covers Integrated Routing and Bridging in 
EVPN, but I could not find any traces of such coverage. Did I miss something, 
or is just a forward declaration for the future version of the draft?

4.   RFC 7432 states that “When a customer site is connected to one or more 
PEs via a set of Ethernet links, then this set of Ethernet links constitutes an 
Ethernet segment". The Virtual Ethernet Segment 
draft 
expands this definition and, so that virtual Ethernet Segments can be comprised 
of:

· Ethernet Virtual Circuits aggregated on an ENNI physical ports

· Ethernet PWs or even MPLS LSPs.
Can you please clarify the following:

a.   How does the proposed YANG data model differentiate between physical 
and virtual Ethernet Segments?

b.   Does this data model cover the scenario where the virtual Ethernet 
segments are represented by EVCs?

5.   RFC 7432 includes recommendations for usage (or non-usage) of the 
Control Word in the EVPN encapsulation, and RFC 8214 (which is claimed to be 
covered by this draft) provides a control plane mechanism for exchanging the CW 
usage information. Can you please clarify whether the draft cover usage of the 
CW in the EVPN encapsulations?
Your feedback will be highly appreciated.

Regards, and lots of thanks in advance,
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.
___


___

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

[bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-mvpn-expl-track-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/



--
DISCUSS:
--

This document places normative requirements on new tunnel types but does
not indicate this in a way that someone specifying a new tunnel type would
be forced to see.  This occurs both in Section 5.2:

   o  When additional tunnel types are defined, the specification for
  how MVPN is to use those tunnel types must also specify how to
  construct the PTA of a Leaf A-D route that is originated in
  response to the LIR-pF flag.  As an example, see [BIER-MVPN].

and in Section 6:

   If L's PTA specifies a tunnel type not mentioned above, the
   specification for how MVPN uses that tunnel type must specify the
   actions that N is to take upon receiving L.  As an example, see
   [BIER-MVPN].

I think the best way to do this would be to have IANA Considerations
updating the registration procedure for
P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
new registrations must include this information.  It might also suffice to
call out the existence of these requirements in the portion of the
Introduction that discusses how this document Updates RFC 6514 (though, per
the COMMENT section, this portion of the Introduction doesn't exist in a
good form yet).

Thank you for providing the BIER example, though -- it is helpful to see
how the requirement plays out in practice!


--
COMMENT:
--

Section 1

   This document clarifies the procedures for originating and receiving
   S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
   procedures to allow more efficient explicit tracking.  The procedures
   being clarified and/or extended are discussed in multiple places in
   the documents being updated.

This is in effect saying to the reader, "you must read the updated
document(s) in their entirety and decide for yourself whether a procedure
being updated is described", which is perhaps not the most friendly thing
to be doing.

Section 2

   If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
   flag of that PTA MUST also be set.

What do I do if I receive a PTA in violation of the MUST?

   Note that support for the LIR-pF flag is OPTIONAL.  This flag SHOULD
   NOT be set unless it is known that all the PEs that are to receive
   the route carrying the PTA support the flag.  How this is known is
   outside the scope of this document.

Maybe remind us what a PE that doesn't support this flag will do if it
happens to receive a PTA with it set?  (I see discussion below of the state
at the ingress node in this case, but not an explicit confirmation of what
egress nodes do.)  It would also be nice to give non-normative examples of
how a sender might know that receivers support the flag.

Section 3

   The rules for finding a "match for reception" in [RFC6625] are hereby
   modified as follows:

Maybe give a section reference too?  (Especially since 6625 does not use
the abbreviated version we define here, and instead writes "Finding the
Match for Data Reception".)

  For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for
  tracking" is chosen as follows.  Ignore any S-PMSI A-D route that
  has no PTA.  Also ignore any S-PMSI A-D route whose PTA specifies
  "no tunnel information present", but does not have either LIR or
  LIR-pF set.  (That is, DO NOT ignore an S-PMSI A-D route that has

I think this would be clearer as "and has neither LIR nor LIR-pF set" --
the "but" can easily lead the reader astray.

  a PTA specifying "no tunnel information present" unless its LIR
  and LIR-pF bits are both clear).  [...]

  Note that the procedure for finding the match for tracking takes
  into account S-PMSI A-D routes whose PTAs specify "no tunnel
  information present" and that have either LIR or LIR-pf set.  The
  procedure for finding the match for reception ignores such routes.

Why are we talking about this like LIR and LIR-pF can be set independently,
when just last page we said that if LIR-pF is set, LIR MUST be set?

Section 4

Please expand I-PMSI on first usage.

   When following this procedure, the PTA of the S-PMSI A-D route
   may specify a tunnel, or may specify "no 

Re: [bess] Questions about the EVPN YANG data model draft

[Patrice Brissette (pbrisset)]

Hi Alex,

I just refresh the draft. Unfortunately, I just notice your email. I will make 
sure it is properly handle.

Regards,

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



From: Alexander Vainshtein 
Date: Sunday, October 21, 2018 at 7:00 AM
To: Patrice Brissette , "hs...@ciena.com" 
, "jorge.raba...@nokia.com" , 
"ing-wher_c...@jabil.com" , "ihuss...@infinera.com" 
, "kisho...@juniper.net" 
Cc: "bess@ietf.org" 
Subject: Questions about the EVPN YANG data model draft

Dear Editors of the EVPN YANG data model 
draft,
I have several questions regarding the draft, and would highly appreciated your 
responses.


1.   The -05 version of the draft has expired almost two months ago. Do you 
plan to refresh it any time soon?

2.   The draft consistently uses type uint32 for the Ethernet segment 
identifier (ESI), while RFC 7432 explicitly defines it as a 10-octet integer. 
Is this just a typo, or did I miss something substantial here?

3.   The draft states that it covers Integrated Routing and Bridging in 
EVPN, but I could not find any traces of such coverage. Did I miss something, 
or is just a forward declaration for the future version of the draft?

4.   RFC 7432 states that “When a customer site is connected to one or more 
PEs via a set of Ethernet links, then this set of Ethernet links constitutes an 
Ethernet segment". The Virtual Ethernet Segment 
draft 
expands this definition and, so that virtual Ethernet Segments can be comprised 
of:

· Ethernet Virtual Circuits aggregated on an ENNI physical ports

· Ethernet PWs or even MPLS LSPs.
Can you please clarify the following:

a.   How does the proposed YANG data model differentiate between physical 
and virtual Ethernet Segments?

b.   Does this data model cover the scenario where the virtual Ethernet 
segments are represented by EVCs?

5.   RFC 7432 includes recommendations for usage (or non-usage) of the 
Control Word in the EVPN encapsulation, and RFC 8214 (which is claimed to be 
covered by this draft) provides a control plane mechanism for exchanging the CW 
usage information. Can you please clarify whether the draft cover usage of the 
CW in the EVPN encapsulations?
Your feedback will be highly appreciated.

Regards, and lots of thanks in advance,
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

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[Ali Sajassi (sajassi)]

Hi Greg,
The text that Stephane mentioned is from “MVPN for PMSI tunnel attribute” and 
not from proposed text for RFC 7432 errata.

Hi Stephane,
I think the provided text in Errata below is sufficient and we don’t need to 
say “The lower order 4 bits SHOULD be sent as 0 and ignored on receipt." In 
case of penultimate hop pop and need to use EXP bits for QoS.

Cheers,
Ali

From: Greg Mirsky 
Date: Monday, October 22, 2018 at 3:07 PM
To: Stephane Litkowski 
Cc: Cisco Employee , "Jakob Heitz (jheitz)" 
, "zhuangshun...@huawei.com" , BESS 

Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.

Hi Stephane,
should note that "setting the MPLS Label field to zero" may be also interpreted 
as a valid label, IPv4 Explicit Null Label.

Regards,
Greg

On Mon, Oct 22, 2018 at 6:47 AM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On 
Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear.

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
mailto:bess-boun...@ietf.org> on behalf of 
jhe...@cisco.com> wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan 
mailto:zhuangshun...@huawei.com>>
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; BESS 
mailto:bess@ietf.org>>
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in the 
low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On 
Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS mailto:bess@ietf.org>>
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>; 
raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; 
aisaa...@bloomberg.net; 
utt...@att.com; 
jdr...@juniper.net; 
wim.henderi...@alcatel-lucent.com; 
db3...@att.com; 
aretana.i...@gmail.com; 
martin.vigour...@nokia.com; Giles Heron 
(giheron) mailto:gihe...@cisco.com>>; 
nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) 
mailto:karum...@cisco.com>>; 
l2...@ietf.org; 
rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP MPLS-Based 
Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 
mailto:karum...@cisco.com>>

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the MPLS 
label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[Greg Mirsky]

Hi Stephane,
should note that "setting the MPLS Label field to zero" may be also
interpreted as a valid label, IPv4 Explicit Null Label.

Regards,
Greg

On Mon, Oct 22, 2018 at 6:47 AM  wrote:

> Hi,
>
> Does anyone disagree with the additional Jakob's statement proposal ?
> " The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."
>
> As an example, in MVPN for PMSI tunnel attribute, we have the following
> statement which does not tell anything about the lower order bits:
> " If the MPLS Label field is non-zero, then it contains an MPLS label
>encoded as 3 octets, where the high-order 20 bits contain the label
>value.  Absence of an MPLS Label is indicated by setting the MPLS
>Label field to zero."
>
>
> Brgds,
>
>
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi
> (sajassi)
> Sent: Tuesday, October 16, 2018 19:30
> To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
> Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.
>
>
> Yes, just the encoding of label value needs to be clear.
>
> Cheers,
> Ali
>
>
>
> On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" <
> bess-boun...@ietf.org on behalf of jhe...@cisco.com> wrote:
>
> How about:
> The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.
>
> Regards,
> Jakob.
>
>
> -Original Message-
> From: Zhuangshunwan 
> Sent: Monday, October 15, 2018 6:02 PM
> To: Jakob Heitz (jheitz) ; BESS 
> Subject: RE: Encoding a 20 bit label in a 24 bit field.
>
> It is good to make this explicit. This ambiguity has led to some
> unnecessary interworking problems.
>
> Should we also need to explicitly define the "bottom of stack" bit in
> the low-order bit of the 3-octet label field?
>
> Thanks,
> Shunwan
>
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz
> (jheitz)
> Sent: Tuesday, October 16, 2018 4:21 AM
> To: BESS 
> Subject: [bess] Encoding a 20 bit label in a 24 bit field.
>
> We have proposed the following erratum for RFC 7432.
>
> Opinions?
>
> Regards,
> Jakob.
>
>
> -Original Message-
> From: RFC Errata System 
> Sent: Friday, October 12, 2018 12:37 PM
> To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com;
> nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com;
> jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com;
> aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron)
> ; nabil.n.bi...@verizon.com
> Cc: Krishnamoorthy Arumugham (karumugh) ;
> l2...@ietf.org; rfc-edi...@rfc-editor.org
> Subject: [Technical Errata Reported] RFC7432 (5523)
>
> The following errata report has been submitted for RFC7432, "BGP
> MPLS-Based Ethernet VPN".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5523
>
> --
> Type: Technical
> Reported by: Krishnamoorthy Arumugham 
>
> Section: 7
>
> Original Text
> -
> Clarifications to following sub-sections:
> Section 7.1
> Section 7.2
> Section 7.5
>
>
> Corrected Text
> --
> Section 7.1:
> Add below text to the section 7.1 regarding the encoding of MPLS label:
>
> "The value of the 20-bit MPLS label is encoded in the high-order 20
> bits of the 3 bytes MPLS Label field."
>
> Section 7.2:
> Add below text to the section 7.2 regarding the encoding of both the
> MPLS label fields:
>
> "The value of the 20-bit MPLS label is encoded in the high-order 20
> bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2.."
>
> Section 7.5:
> Add below text to the section 7.5 regarding the encoding of ESI Label
> fields:
>
> "The value of the 20-bit MPLS label is encoded in the high-order 20
> bits of the ESI Label field."
>
>
> Notes
> -
> MPLS label is a 20-bit value and is stored in a 3 bytes field in a
> packet. The 20-bit MPLS label value is generally stored in higher order 20
> bits of the 3 byte label field. The exact encoding to be followed for
> storing MPLS label values are not explicitly mentioned in the RFC 7432
> under section 7.1, 7.2 and 7.5 for different types of EVPN routes. This
> lead to ambiguity in different implementations. Hence a clarification is
> required.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC7432 (draft-ietf-l2vpn-evpn-11)
> --
> Title   : BGP MPLS-Based 

[bess] I-D Action: draft-ietf-bess-evpn-yang-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Yang Data Model for EVPN
Authors : Patrice Brissette
  Himanshu Shah
  Iftekar Hussain
  Kishore Tiruveedhula
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-yang-06.txt
Pages   : 28
Date: 2018-10-22

Abstract:
   This document describes a YANG data model for Ethernet VPN services.
   The model is agnostic of the underlay. It apply to MPLS as well as to
   VxLAN encapsulation. The model is also agnostic of the services
   including E-LAN, E-LINE and E-TREE services. This document mainly
   focuses on EVPN and Ethernet-Segment instance framework.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-yang-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[Jakob Heitz (jheitz)]

I think it's cleaner to make the statement, but I don't think it matters to 
omit the statement.
Even if there was a BOS, it would be ignored.
The extcomm carries a single label. Exactly one. It's not a stack.
When the label eventually gets imposed onto a stack, that stack will have its 
own bottom, regardless of any BOS bit on our precious label.

Regards,
Jakob.

-Original Message-
From: Acee Lindem (acee) 
Sent: Monday, October 22, 2018 7:58 AM
To: stephane.litkow...@orange.com; Ali Sajassi (sajassi) ; 
Jakob Heitz (jheitz) ; Zhuangshunwan 
; BESS 
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.

Hi Stephane, 
No objection - I think the question on whether BOS should be encoded in those 
bits confirms that this should be specified. 
Thanks,
Acee

On 10/22/18, 9:47 AM, "BESS on behalf of stephane.litkow...@orange.com" 
 wrote:

Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear. 

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
 wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan  
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) ; BESS 
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in 
the low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz 
(jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS 
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com; 
jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com; 
aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron) 
; nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) ; 
l2...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP 
MPLS-Based Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the 
MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of ESI Label 
fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the ESI Label field."


Notes
 

[bess] I-D Action: draft-ietf-bess-l2vpn-yang-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : YANG Data Model for MPLS-based L2VPN
Authors : Himanshu Shah
  Patrice Brissette
  Ing-When Chen
  Iftekar Hussain
  Bin Wen
  Kishore Tiruveedhula
Filename: draft-ietf-bess-l2vpn-yang-09.txt
Pages   : 48
Date: 2018-10-22

Abstract:
   This document describes a YANG data model for Layer 2 VPN (L2VPN)
   services over MPLS networks.  These services include point-to-point
   Virtual Private Wire Service (VPWS) and multipoint Virtual Private
   LAN service (VPLS) that uses LDP and BGP signaled Pseudowires.  It is
   expected that this model will be used by the management tools run by
   the network operators in order to manage and monitor the network
   resources that they use to deliver L2VPN services.

   This document also describes the YANG data model for the Pseudowires.
   The independent definition of the Pseudowires facilitates its use in
   Ethernet Segment and EVPN data models defined in separate document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2vpn-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-09
https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2vpn-yang-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2vpn-yang-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[Acee Lindem (acee)]

Hi Stephane, 
No objection - I think the question on whether BOS should be encoded in those 
bits confirms that this should be specified. 
Thanks,
Acee

On 10/22/18, 9:47 AM, "BESS on behalf of stephane.litkow...@orange.com" 
 wrote:

Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear. 

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
 wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan  
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) ; BESS 
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in 
the low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz 
(jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS 
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com; 
jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com; 
aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron) 
; nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) ; 
l2...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP 
MPLS-Based Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the 
MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of ESI Label 
fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 
bits of the ESI Label field."


Notes
-
MPLS label is a 20-bit value and is stored in a 3 bytes field in a 
packet. The 20-bit MPLS label value is generally stored in higher order 20 bits 
of the 3 byte label field. The exact encoding to be followed for storing MPLS 
label values are not explicitly mentioned in the RFC 7432 under section 7.1, 
7.2 and 7.5 for different types of EVPN routes. This lead to ambiguity in 
different implementations. Hence a clarification is required.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss 

Re: [bess] Comments on L3VPN yang

[stephane.litkowski]

I'm also wondering if the RPF should not sit in the MPLS module as it could be 
used for any types of labels advertised to a neighbor.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, October 22, 2018 15:25
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
Subject: [bess] Comments on L3VPN yang

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related..

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_



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.

_

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 

Re: [bess] Comments on L3VPN yang

[Alexander Vainshtein]

Hi all,
I fully agree with Stephane's point "the label mode should sit within the VRF 
and not at the BGP level. Each VRF may have a different flavor".  One relevant 
use case is the VRF that provides inet-subnet forwarding i EVPN with Symmetric 
IRB - it must use per-VRF label allocation policy with the label in question 
being advertised ad Label2 in MAC/IP Advertisement routes rgardless of how 
other VRFs allocate their labels.

My 2c.

Thumb typed by Sasha Vainshtein


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

Sent: Monday, October 22, 2018 4:24:35 PM
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
Subject: [bess] Comments on L3VPN yang

Hi Authors,

Please find some comments on the current model:

-  I don’t understand the “advertise-as-vpn” leaf under global-imports, 
what is the use case ?

-  Same question for “bgp-valid-route” leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn’t it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just “.”

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the “forwarding-mode” under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn’t it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the “route-policy” within 
“retain-route-targets” under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the “vpn-prefix-limit” within “retain-route-targets” under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related..

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier’s of Carrier case ?


Brgds,

Stephane


_

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.


___

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

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[stephane.litkowski]

Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear. 

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
 wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan  
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) ; BESS 
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in the 
low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS 
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com; 
jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com; 
aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron) 
; nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) ; 
l2...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP MPLS-Based 
Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the MPLS 
label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of ESI Label 
fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the ESI Label field."


Notes
-
MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet. 
The 20-bit MPLS label value is generally stored in higher order 20 bits of the 
3 byte label field. The exact encoding to be followed for storing MPLS label 
values are not explicitly mentioned in the RFC 7432 under section 7.1, 7.2 and 
7.5 for different types of EVPN routes. This lead to ambiguity in different 
implementations. Hence a clarification is required.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7432 (draft-ietf-l2vpn-evpn-11)
--
Title   : BGP MPLS-Based Ethernet VPN
Publication Date: February 2015
Author(s)   : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. 
Uttaro, J. Drake, W. Henderickx
Category: PROPOSED STANDARD
Source  : Layer 2 Virtual Private Networks
Area: Routing
Stream  : IETF
Verifying Party : IESG

[bess] Comments on L3VPN yang

[stephane.litkowski]

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related.

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_

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

[bess] LxVPN and EVPN yang models

[stephane.litkowski]

Hi Authors,


Speaking as individual, after reading the last versions of your module, I still 
have several concerns about the consistency of the modeling across all models.
There are common components between all the models that could be shared or at 
least modeled in the same way:

-  Model name: L3VPN uses ietf-bgp-l3vpn while others use ietf-evpn or 
ietf-l2vpn

-  Route-target import/export and route-distinguisher:

o   Under bgp-parameters/common/rd-rt/ for EVPN

o   Under bgp-auto-discovery for L2VPN (that could make sense here but it is 
weird in term of config consistency => maybe better to have a 
bgp-auto-discovery Boolean or maybe the discovery-type is enough to know that 
bgp-auto-discovery is used ?)

o   Under ipv4 or ipv6 for l3vpn RTs but rd is at top level. That could make 
sense but again the configuration is slightly different from other AFI/SAFIs. 
Having different imp/exp for IPv4 and IPv6 is a valid use case, but you should 
also allow to have the same config for both without defining per AFI/SAFI 
config.

-  RIB route limits could also be modeled the same way

-  Modelization of route entries in the RIB could be modeled in the 
same way across model

-  Attachment to the NI:

o   I don't understand how EVPN is integrated in L2VPN. It seems that you add a 
pointer (reference) to an EVPN instance which is in a completely different 
tree. That looks really strange and make EVPN instance configuration completely 
different from an L3VPN instance or L2VPN instance. Do you plan to reuse the 
config parameters from L2VPN or do you prefer creating a completely different 
tree ? If you prefer a completely different tree why not creating an EVPN 
ni-type ?


Can't we have one model defining some bgp-vpn containers possibly as a separate 
module that could be reused across all models ?

Happy to hear your feedback.

Brgds,

Stephane


_

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

[bess] I-D Action: draft-ietf-bess-evpn-pref-df-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Preference-based EVPN DF Election
Authors : Jorge Rabadan
  Senthil Sathappan
  Tony Przygienda
  Wen Lin
  John Drake
  Ali Sajassi
  Satya Ranjan Mohanty
Filename: draft-ietf-bess-evpn-pref-df-02.txt
Pages   : 13
Date: 2018-10-22

Abstract:
   The Designated Forwarder (DF) in (PBB-)EVPN networks is defined as
   the PE responsible for sending broadcast, multicast and unknown
   unicast traffic (BUM) to a multi-homed device/network in the case of
   an all-active multi-homing ES, or BUM and unicast in the case of
   single-active multi-homing.

   The DF is selected out of a candidate list of PEs that advertise the
   Ethernet Segment Identifier (ESI) to the EVPN network, according to
   the Default DF Election algorithm.

   While the Default Algorithm provides an efficient and automated way
   of selecting the DF across different EVIs or ISIDs in the ES, there
   are some use-cases where a more 'deterministic' and user-controlled
   method is required. At the same time, Service Providers require an
   easy way to force an on-demand DF switchover in order to carry out
   some maintenance tasks on the existing DF or control whether a new
   active PE can preempt the existing DF PE.

   This document proposes an extension to the Default DF election
   procedures so that the above requirements can be met.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-02
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-pref-df-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[bess] Publication has been requested for draft-ietf-bess-evpn-optimized-ir-06

[Matthew Bocci]

Matthew Bocci has requested publication of draft-ietf-bess-evpn-optimized-ir-06 
as Proposed Standard on behalf of the BESS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/

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