[bess] I-D Action: draft-ietf-bess-evpn-vpws-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 of the IETF.

Title   : VPWS support in EVPN
Authors : Sami Boutros
  Ali Sajassi
  Samer Salam
  John Drake
  Jeff Tantsura
  Dirk Steinberg
  Thomas Beckhaus
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-vpws-06.txt
Pages   : 13
Date: 2016-06-07

Abstract:
   This document describes how EVPN can be used to support Virtual
   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
   following characteristics for VPWS: single-active as well as all-
   active multi-homing with flow-based load-balancing, eliminates the
   need for traditional way of PW signaling, and provides fast
   protection convergence upon node or link failure.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-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

[bess] I-D Action: draft-ietf-bess-evpn-vpws-05.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 of the IETF.

Title   : VPWS support in EVPN
Authors : Sami Boutros
  Ali Sajassi
  Samer Salam
  John Drake
  Jeff Tantsura
  Dirk Steinberg
  Thomas Beckhaus
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-vpws-05.txt
Pages   : 14
Date: 2016-06-07

Abstract:
   This document describes how EVPN can be used to support Virtual
   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
   following characteristics for VPWS: single-active as well as all-
   active multi-homing with flow-based load-balancing, eliminates the
   need for traditional way of PW signaling, and provides fast
   protection convergence upon node or link failure.



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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-05

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


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] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

[John E Drake]

This sounds like a plan.

Yours Irrespectively,

John

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
> Sent: Tuesday, June 07, 2016 12:04 PM
> To: Martin Vigoureux; bess@ietf.org
> Cc: Ali Sajassi (sajassi)
> Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. 
> draft-ietf-idr-tunnel-encaps
> 
> 
> Hi Martin,
> 
> We¹ll also add idr-tunnel-encaps a Informative reference. With respect to 
> Tunnel Encap
> Extended Community (which is the only part of idr-tunnel-encap used by 
> evpn-overlay
> draft), idr-tunel-encap draft itself references RFC 5512.
> 
> During the course of WG LC and RFC editorship of evpn-overlay draft, if we 
> see that idr-
> tunnel-encap is progressing fast, then we can drop the reference to RFC 5512 
> and make the
> reference to idr-tunnel-encap Normative. Otherwise, we¹ll keep both 
> references with RFC
> 5512 as Normative and idr-tunnel-encap as Informative.
> 
> Regards,
> Ali
> 
> On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"
>  wrote:
> 
> >Hi,
> >
> >We are fine with keeping 5512 as the Normative reference for now.
> >We would think it wise if the editors can add an Informative reference
> >to draft-ietf-idr-tunnel-encaps (with some text indicating that both
> >specs provide the required support for the procedures).
> >The ideal situation would be that tunnel-encaps progresses fast enough
> >so that in the last stages before publishing evpn-overlay we can be in
> >a situation to make tunnel-encaps the Normative reference. RFC 4897
> >would facilitate that by the way.
> >
> >If the WG has specific opinions on that matter, they are welcome.
> >
> >We take good note of the shepherd suggestion. We'll confirm who will
> >shepherd the document after WG LC (we'll also call for volunteers
> >during WG Last Call).
> >
> >Reviews are highly welcome anyway, in particular from people close to
> >the topic or implementations, and ideally from more than one person,
> >the best time being now or at least before the WG LC ends.
> >
> >We'll start the WG LC in a couple of days.
> >
> >Martin & Thomas
> >
> >
> >Le 24/05/2016 15:39, John E Drake a écrit :
> >> Hi,
> >>
> >> Ali and I decided to keep the normative reference to RFC 5512 rather
> >> than changing it to Eric¹s tunnel encapsulation draft because the
> >> normative reference pre-dates Eric¹s draft and because our draft does
> >> not use any of the new capabilities introduced in Eric¹s draft.
> >>
> >> Ali and I would also like to request that Jorge be the document
> >> shepherd for this draft.
> >>
> >> Yours Irrespectively,
> >>
> >> John
> >>
> >> *From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
> >> *Sent:* Tuesday, May 24, 2016 3:05 AM
> >> *To:* John E Drake; EXT - thomas.mo...@orange.com; IDR; BESS;
> >> draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia -
> >> US); draft-ietf-idr-tunnel-en...@tools.ietf.org
> >> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
> >> draft-ietf-idr-tunnel-encaps
> >>
> >> Folks,
> >>
> >> I have updated and published rev03 of even-overlay draft.
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/
> >>
> >> The main changes are:
> >>
> >>  1. section 10.2 ­ DCI using ASBR
> >>  2. The setting of Ethernet tag and VNI fields ­ there were some
> >> inconsistencies in different sections. Section 5.1.3 captures the
> >> setting of these fields for different type of services in pretty
> >> good details. All other sections were cleaned up and now refer to
> >> section 5.1.3.
> >>
> >> Thomas,
> >>
> >> The draft is ready for its long-overdue WG LC considering how long
> >> its has been around and its multi-vendor implementation status.
> >>
> >> Regards,
> >>
> >> Ali
> >>
> >>
> >>
> >> ___
> >> BESS mailing list
> >> BESS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/bess
> >>
> >
> >___
> >BESS mailing list
> >BESS@ietf.org
> >https://www.ietf.org/mailman/listinfo/bess
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

[Ali Sajassi (sajassi)]

Hi Martin,

We¹ll also add idr-tunnel-encaps a Informative reference. With respect to
Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself
references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if we
see that idr-tunnel-encap is progressing fast, then we can drop the
reference to RFC 5512 and make the reference to idr-tunnel-encap
Normative. Otherwise, we¹ll keep both references with RFC 5512 as
Normative and idr-tunnel-encap as Informative.

Regards,
Ali

On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hi,
>
>We are fine with keeping 5512 as the Normative reference for now.
>We would think it wise if the editors can add an Informative reference
>to draft-ietf-idr-tunnel-encaps (with some text indicating that both
>specs provide the required support for the procedures).
>The ideal situation would be that tunnel-encaps progresses fast enough
>so that in the last stages before publishing evpn-overlay we can be in a
>situation to make tunnel-encaps the Normative reference. RFC 4897 would
>facilitate that by the way.
>
>If the WG has specific opinions on that matter, they are welcome.
>
>We take good note of the shepherd suggestion. We'll confirm who will
>shepherd the document after WG LC (we'll also call for volunteers during
>WG Last Call).
>
>Reviews are highly welcome anyway, in particular from people
>close to the topic or implementations, and ideally from more than one
>person, the best time being now or at least before the WG LC ends.
>
>We'll start the WG LC in a couple of days.
>
>Martin & Thomas
>
>
>Le 24/05/2016 15:39, John E Drake a écrit :
>> Hi,
>>
>> Ali and I decided to keep the normative reference to RFC 5512 rather
>> than changing it to Eric¹s tunnel encapsulation draft because the
>> normative reference pre-dates Eric¹s draft and because our draft does
>> not use any of the new capabilities introduced in Eric¹s draft.
>>
>> Ali and I would also like to request that Jorge be the document shepherd
>> for this draft.
>>
>> Yours Irrespectively,
>>
>> John
>>
>> *From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
>> *Sent:* Tuesday, May 24, 2016 3:05 AM
>> *To:* John E Drake; EXT - thomas.mo...@orange.com; IDR; BESS;
>> draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia -
>> US); draft-ietf-idr-tunnel-en...@tools.ietf.org
>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
>> draft-ietf-idr-tunnel-encaps
>>
>> Folks,
>>
>> I have updated and published rev03 of even-overlay draft.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/
>>
>> The main changes are:
>>
>>  1. section 10.2 ­ DCI using ASBR
>>  2. The setting of Ethernet tag and VNI fields ­ there were some
>> inconsistencies in different sections. Section 5.1.3 captures the
>> setting of these fields for different type of services in pretty
>> good details. All other sections were cleaned up and now refer to
>> section 5.1.3.
>>
>> Thomas,
>>
>> The draft is ready for its long-overdue WG LC considering how long its
>> has been around and its multi-vendor implementation status.
>>
>> Regards,
>>
>> Ali
>>
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess

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

[bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

Hi Jeffrey,
   Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib
document. It took me some time to do this review. But now here it
is. A (near complete) review of  
draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps.

   I understand that the Security Considerations section is TBD.

   Glenn

On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote:

Hi Glenn,


-Original Message-
From: Glenn Mansfield Keeni [mailto:gl...@cysols.com]
Sent: Sunday, May 08, 2016 11:02 AM
To: Jeffrey (Zhaohui) Zhang ; Benoit Claise
; EXT - thomas.mo...@orange.com

Cc: Mach Chen ; ops-...@ietf.org; Martin Vigoureux
; bess@ietf.org; mib-doct...@ietf.org
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-
02.txt

Jeffrey,
 > Thanks for your comments. I've addressed most of your comments
 > in the new revision:
Thanks for your cooperation. I will need at least one more revision
with the following comments/recommendations addressed before I will
be able to complete the detailed review. In the following the numbers
refer to the issue numbers in the initial review. The issues that are
addressed and closed are not listed. For brevity, the issue
descriptions have been trimmed. In case of doubts please look at the
response mail appended below.
Hope this helps.


Thanks for your detailed comments/suggestions. I posted a new revision with the 
following issues addressed.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04

Please see some notes below.



Glenn

---

Comments:

1.1
 >  I had thought this would be standard/obvious for all MIB objects -
We will comeback to this time and again, whereever possible make
matters explicit and clear. That will help.
 >  Is it enough to say something similar? For example:
 >  In particular, it describes common managed objects used
 >  to configure and/or monitor both L2 and L3 VPN Multicast.
That is better.


I take it that this is already closed in -03 revision.



2.2
 >  Having said that, I'll explain PMSI a bit further.
PMSI explanation is good.
Please use the same style/format for I-PMSI and S-PMSI.


I think -03 revision already use the same style/format for I-PMSI and S-PMSI?



2.3
 >  No difference. I was using "Layer 3" or "L3" but it was pointed out
 > that the layer 3 VPN is often referred to IP VPN in other RFCs and I
 > was advised to change it accordingly. Looks like I did not change all
 > the cases.
 >  On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so
 > I'll change it back.
No problems. just make sure that the same expression/notation is used
uniformly.


I take it that this is also addressed in -03 already.


3.
 >  > > 3.  Summary of MIB Module.
 >  > > An overview of the L2L3-VPN-MCAST-MIB will be good- the
 >  > > structure of the MIB, short descriptions of the table(s)
 >  > > including usage of the table(s) for management and/or by
 >  > > other MIB(s).
 >
 >  I had that, but have added one sentence about the only table.
A sentence or two about the textual convention will be good.


Added in -04.


 >  > > 4. MIB syntax checking:
 >  > >smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt
 >
 >  I used simpleweb's validation tool but looks like I did not use the
 > strictest level of validation. I've now fixed the following issues and
 > verified.
Good.
5.
 >  > >
 >  > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally.
 >  > >Wherever possible, provide references for objects used in
 >  > >the MIB. The references will point to specific sections/
 >  > >sub-sections of the RFCs defining the protocol for which the
 >  > >MIB is being designed. It will greatly improve the readability
 >  > >of the document.
 >
 >  Added.
I would recommend using the REFERENCE clause as in rfs4382 and
improve on it.
Specifically, instead of keeping the reference in the DESCRIPTION
clause move it to a separate REFERENCE clause. The addition of the
section number is an improvement. It is friendlier to the reader.
Note. Same comment for other OBJECTs too.


Oh I missed that. All fixed.


7.1
 >  > > 7.1 CONTACT-INFO
 >  > > Following the conventions (including indentation style) will
 >  > > improve the readability. (e.g. RFC4382, RFC5132).
 >  > > Will be good if it does not overflow into the next page.
 >
 >  Fixed.
The format is OK. The Postal address etc., need not have been
deleted. Please put the complete contact information as in the
Author's 

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

[Martin Vigoureux]

Hi,

We are fine with keeping 5512 as the Normative reference for now.
We would think it wise if the editors can add an Informative reference 
to draft-ietf-idr-tunnel-encaps (with some text indicating that both 
specs provide the required support for the procedures).
The ideal situation would be that tunnel-encaps progresses fast enough 
so that in the last stages before publishing evpn-overlay we can be in a 
situation to make tunnel-encaps the Normative reference. RFC 4897 would 
facilitate that by the way.


If the WG has specific opinions on that matter, they are welcome.

We take good note of the shepherd suggestion. We'll confirm who will 
shepherd the document after WG LC (we'll also call for volunteers during 
WG Last Call).


Reviews are highly welcome anyway, in particular from people
close to the topic or implementations, and ideally from more than one
person, the best time being now or at least before the WG LC ends.

We'll start the WG LC in a couple of days.

Martin & Thomas


Le 24/05/2016 15:39, John E Drake a écrit :

Hi,

Ali and I decided to keep the normative reference to RFC 5512 rather
than changing it to Eric’s tunnel encapsulation draft because the
normative reference pre-dates Eric’s draft and because our draft does
not use any of the new capabilities introduced in Eric’s draft.

Ali and I would also like to request that Jorge be the document shepherd
for this draft.

Yours Irrespectively,

John

*From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
*Sent:* Tuesday, May 24, 2016 3:05 AM
*To:* John E Drake; EXT - thomas.mo...@orange.com; IDR; BESS;
draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia -
US); draft-ietf-idr-tunnel-en...@tools.ietf.org
*Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps

Folks,

I have updated and published rev03 of even-overlay draft.

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/

The main changes are:

 1. section 10.2 – DCI using ASBR
 2. The setting of Ethernet tag and VNI fields – there were some
inconsistencies in different sections. Section 5.1.3 captures the
setting of these fields for different type of services in pretty
good details. All other sections were cleaned up and now refer to
section 5.1.3.

Thomas,

The draft is ready for its long-overdue WG LC considering how long its
has been around and its multi-vendor implementation status.

Regards,

Ali



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



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