[bess] FW: Last Call: (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

[Alvaro Retana (aretana)]

FYI…

Please take a look.  If anyone has comments, please reply to the thread in the 
i...@ietf.org list.

Thanks!

Alvaro.

On 9/13/17, 10:04 AM, "IETF-Announce on behalf of The IESG" 
 wrote:


The IESG has received a request from an individual submitter to consider the
following document: - 'YANG Data Model for L3VPN Service Delivery'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 provider-provisioned VPN service.  This document is limited
   to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
   model is intended to be instantiated at the management system to
   deliver the overall service.  It is not a configuration model to be
   used directly on network elements.  This model provides an abstracted
   view of the Layer 3 IP VPN service configuration components.  It will
   be up to the management system to take this model as input and use
   specific configuration models to configure the different network
   elements to deliver the service.  How the configuration of network
   elements is done is out of scope for this document.

   If approved, this document obsoletes RFC 8049.  The changes are a
   series of small fixes to the YANG module, and some clarifications to
   the text.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ballot/

No IPR declarations have been submitted directly on this I-D.

Working Group Summary
  RFC 8049 was the product of the L3SM working group, but that WG has been 
closed.
  No other WG covers this topic.
  However, the L3SM list remains open: changes and revisions were publicised 
and discussed there

The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc3022: Traditional IP Network Address Translator (Traditional NAT) 
(Informational - IETF stream)





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

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

[Alvaro Retana (aretana)]

I was referring to this document being marked as Updating rfc7385.

In any case, that works for me.

Thanks!

Alvaro.

On 8/22/17, 10:41 AM, "Ali Sajassi (sajassi)" 
<saja...@cisco.com<mailto:saja...@cisco.com>> wrote:

Hi Alvaro,

I am not modifying rfc7385 but rather trying to maintain backward/forward 
compatibility with it. The reason, I am defining additional “experimental" and 
“reserved” code points, is to maintain backward/forward compatibility with the 
rfc7385 code points. The new “experimental” and “reserved” code points (i.e., 
0x7B – 0x7E, and 0x7F) are mirror images of the ones in rfc7385 (i.e., 0xFB – 
0xFE, and 0xFF). If I don’t create these mirror images and leave them 
“unassigned”, then if somebody creates a tunnel type of 0x7B, then the 
corresponding composite tunnel type of that would be 0xFB which will conflict 
with existing code points in rfc7385 (i.e., 0xFB is defined as experimental).

Cheers,
Ali

From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>
Date: Monday, August 21, 2017 at 6:26 PM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, "Carlos 
Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"ops-...@ietf.org<mailto:ops-...@ietf.org>" 
<ops-...@ietf.org<mailto:ops-...@ietf.org>>
Cc: 
"draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>"
 
<draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12

Ali:

Hi!

RFC7385 already defines an Experimental range, why do we need another one?  
Same question about reserving 0x7F (if rfc7385 already reserved 0xFF).

One of the reasons I’m asking is because if you’re only changing the 0x0C – 
0xFA range, which is currently unassigned, the you (1) only need to include 
those values in this document, and (2) you don’t need to Update rfc7385:

Thanks!

Alvaro.


On 8/21/17, 5:47 PM, "Ali Sajassi (sajassi)" 
<saja...@cisco.com<mailto:saja...@cisco.com>> wrote:


Trying for the 2nd time because of the format scramble in the previous email.

Value   MeaningReference
0x0C-0x7A  Unassigned
0x7B-0x7E  Experimentalthis document
0x7FReserved   this document
0x80-0xFA  Reserved for Composite tunnel  this document
0xFB-0xFE  Experimental[RFC7385]
0xFF        Reserved   [RFC7385]


From: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Monday, August 21, 2017 at 5:14 PM
To: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"ops-...@ietf.org<mailto:ops-...@ietf.org>" 
<ops-...@ietf.org<mailto:ops-...@ietf.org>>
Cc: 
"draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>"
 
<draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<ssa...@cisco.com<mailto:ssa...@cisco.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<ju1...@att.com<mailto:ju1...@att.com>>, 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>, 
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>, 
<aret...@cisco.com<mailto:aret...@cisco.com>>, 
<db3...@att.com<mailto:db3...@att.com>>, 
<akat...@gmail.com<mailto:akat...@gmail.com>>, Thomas Morin 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Resent-Date: Monday, August 21, 2017 at 5:15 PM


Hi Alvaro,

You’re right. I had some holes in my assignment. Following should fix it.

   ValueMeaningReference
   0x0C-0x7AUnassigned
   0x7B-0x7EExperimentalthis document
   0x7FReservedthis document
   0x80-0xFAReserved for Composite tunnelthis document
   0xFB-0xFEExperimental RFC7385]
   0xFFReserved[RFC7385]

Thanks,
Ali

From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cis

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

[Alvaro Retana (aretana)]

Ali:

Hi!

RFC7385 already defines an Experimental range, why do we need another one?  
Same question about reserving 0x7F (if rfc7385 already reserved 0xFF).

One of the reasons I’m asking is because if you’re only changing the 0x0C – 
0xFA range, which is currently unassigned, the you (1) only need to include 
those values in this document, and (2) you don’t need to Update rfc7385:

Thanks!

Alvaro.


On 8/21/17, 5:47 PM, "Ali Sajassi (sajassi)" 
<saja...@cisco.com<mailto:saja...@cisco.com>> wrote:


Trying for the 2nd time because of the format scramble in the previous email.

Value   MeaningReference
0x0C-0x7A  Unassigned
0x7B-0x7E  Experimentalthis document
0x7FReserved   this document
0x80-0xFA  Reserved for Composite tunnel  this document
0xFB-0xFE  Experimental[RFC7385]
0xFFReserved   [RFC7385]


From: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Monday, August 21, 2017 at 5:14 PM
To: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"Carlos Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"ops-...@ietf.org<mailto:ops-...@ietf.org>" 
<ops-...@ietf.org<mailto:ops-...@ietf.org>>
Cc: 
"draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>"
 
<draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<ssa...@cisco.com<mailto:ssa...@cisco.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<ju1...@att.com<mailto:ju1...@att.com>>, 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>, 
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>, 
<aret...@cisco.com<mailto:aret...@cisco.com>>, 
<db3...@att.com<mailto:db3...@att.com>>, 
<akat...@gmail.com<mailto:akat...@gmail.com>>, Thomas Morin 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>
Resent-Date: Monday, August 21, 2017 at 5:15 PM


Hi Alvaro,

You’re right. I had some holes in my assignment. Following should fix it.

   Value MeaningReference
   0x0C-0x7A Unassigned
   0x7B-0x7E Experimentalthis document
   0x7F Reservedthis document
   0x80-0xFA Reserved for Composite tunnelthis document
   0xFB-0xFE Experimental RFC7385]
   0xFF Reserved[RFC7385]

Thanks,
Ali

From: "Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>
Date: Monday, August 21, 2017 at 1:05 PM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, "Carlos 
Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"ops-...@ietf.org<mailto:ops-...@ietf.org>" 
<ops-...@ietf.org<mailto:ops-...@ietf.org>>
Cc: 
"draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>"
 
<draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-etree-12

Ali:

Hi!

So, you’re really only changing the 0x0C – 0xFA range, right?

If my hex is not wrong, you’re missing some pieces below: 0x40-0x7F, and 
0xC0-0xCF, which I’m assume remain Unassigned, right?

Thanks!

Alvaro.

On 8/16/17, 5:54 PM, "Ali Sajassi (sajassi)" 
<saja...@cisco.com<mailto:saja...@cisco.com>> wrote:

To maximize backward/forward compatibility, let's retain the value for 
"Experimental Use” and “Reserved” as before per [RFC7385] and reduce the range 
for Composite tunnel for this draft. So, the changes will be
From existing IANA assignments:
0x0C - 0xFA Unassigned
0xFB - 0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
To:
  0x0C – 0x3F Unassigned
  0x80 – 0xBF reserved for composite tunnel
  0xD0 – 0xFA Unassigned
  0xFB - 0xFE Experimental [RFC7385]
  0xFF
 Reserved [RFC7385]



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

Re: [bess] draft-ietf-bess-evpn-overlay-08

[Alvaro Retana (aretana)]

I know it’s there.

I’ve been working on the spring documents which are taking up more time than I 
expected.

BTW, you can follow at home here:  
https://datatracker.ietf.org/doc/ad/alvaro.retana/

Thanks!

Alvaro.

On 6/23/17, 2:10 AM, "Ali Sajassi (sajassi)" 
> wrote:

Once you are done with the evpn-etree, I’d like to bring to your attention this 
draft which has been sitting in the queue for  IESG review for a while.


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

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" 
> wrote:

Ali:

Hi!  Sorry for the long RTT, busy days…

I have two remaining comments (below).  Once the registry is defined, then we 
can start the IESTF LC.

Thanks!

Alvaro.


…
> > > M6. Definition of the E-TREE Extended Community
> > >
> > > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > > registry.
> >
> > If needed in the future, we will setup a registry.
>
> Please set it up now.
>
> OK, I will set it up.

Please do.


…
> > > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 
> > > says that “the high-
> > > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > > while the
> > > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > > 3.3.1 says
> > > that the “new composite tunnel type is advertised by the root PE to 
> > > simultaneously
> > > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > > tunnel in the
> > > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > > set meaning
> > > or ???   [BTW, s/is/are]
> >
> > The description in section 3.3.1 is consistent with this section 5.2. 
> > Basically, Composite
> > Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in 
> > the transmit
> > direction and a MP2P tunnel in the receive direction. The MP2P tunnel in 
> > the receive
> > direction is used by Leaf PE devices for their BUM traffic transmission. 
> > The "ingress
> > replication tunnel type” is not valid because for that we don’t need 
> > composite tunnel
> > type!!
> > I added the following sentence to the 1st paragraph to clarify it  more:
> > "Composite tunnel type is advertised by the root PE to simultaneously 
> > indicate a P2MP
> > tunnel in transmit direction and an ingress-replication tunnel in the 
> > receive direction
> > for the BUM traffic."
>
> Let me see if I understand what you’re saying:
>
> If the C-bit is set, then the receive direction always has an IR tunnel.
> The type of the P2MP tunnel is defined by one of the other bits.  Is that 
> right?
>
> That’s correct. The remaining 7 bits indicate the type of tunnel.
>
> If so, are all the other bits valid (always)?  The text already says that 
> 0x00/0x06 are
> invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 0x0A 
> (Assisted-Replication
>  Tunnel [draft-ietf-bess-evpn-optimized-ir])?
>
> How can you be sure that any other type besides 0x00/0x06 will be ok?
>
> Basically composite tunnel type doesn’t make sense when ingress replication 
> (0x06)
> is used or when tunnel info is not present (0x00). Other than that, it can be 
> used with
> other tunnel types.

I was asking about 0x07 because that is a MP2MP LSP, and the text says that the 
bits “indicate a P2MP tunnel”:  P2MP, but not other types.  Maybe the solution 
is to just say “indicate a tunnel”.

You said that IR doesn’t make sense, but “optimized IR” does?  I’ll take your 
work for it…

Just double checking, no change needed (except s/P2MP//) if any other tunnel 
can be used.



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

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" 
> wrote:

Ali:

Hi!

We’re on the right path, but not there yet.  Please see my comments inline 
below.

Thanks!

Alvaro.


…
> > M1. Both the Introduction and the Abstract mention that “this document 
> > discusses
> > how the functional requirements for E-Tree service can be easily met…”  It 
> > seems to
> > me that RFC7387 is used as the building block for this document.  Why is it 
> > not a
> > Normative reference?
>
> Because RFC7387 is informational RFC (and the framework RFC) and the idnits
> complains of a downref: Normative reference to an informational RFC

The status of an RFC is not an indicator of how it should be referenced – 
complaints from idnits is not an excuse.  IOW, there is nothing that prevents 
an Informational document to be referenced as Normative – we just need to take 
care of the process: not a big deal, but important.

Let me rephrase.  Is rfc7387 a document that “that must be read to understand 
or implement” [1] what is specified in this document?  Because of how rfc7387 
is positioned in the Abstract/Introduction, it seems to me that the framework 
must be read to then understand how this document addresses it:


“ A solution

   framework for supporting this service in MPLS networks is proposed in

   RFC7387 ("A Framework for Ethernet Tree 
(E-Tree) Service over a

   Multiprotocol Label Switching (MPLS) Network"). This document

   discusses how those functional requirements can be easily met with

   Ethernet VPN (EVPN) and how EVPN offers a more efficient

   implementation of these functions.”

[1] https://www.ietf.org/iesg/statement/normative-informative.html


> > M2. There is no reference to E-Tree.  Please add a Normative one.
>
> Added a reference for E-TREE definition in MEF.

This reference needs to be Normative – see above.


…
> > M6. Definition of the E-TREE Extended Community
> >
> > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > registry.
>
> If needed in the future, we will setup a registry.

Please set it up now.

…
> > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says 
> > that “the high-
> > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > while the
> > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > 3.3.1 says
> > that the “new composite tunnel type is advertised by the root PE to 
> > simultaneously
> > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > tunnel in the
> > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > set meaning
> > or ???   [BTW, s/is/are]
>
> The description in section 3.3.1 is consistent with this section 5.2. 
> Basically, Composite
> Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in the 
> transmit
> direction and a MP2P tunnel in the receive direction. The MP2P tunnel in the 
> receive
> direction is used by Leaf PE devices for their BUM traffic transmission. The 
> "ingress
> replication tunnel type” is not valid because for that we don’t need 
> composite tunnel
> type!!
> I added the following sentence to the 1st paragraph to clarify it  more:
> "Composite tunnel type is advertised by the root PE to simultaneously 
> indicate a P2MP
> tunnel in transmit direction and an ingress-replication tunnel in the receive 
> direction
> for the BUM traffic."

Let me see if I understand what you’re saying:

If the C-bit is set, then the receive direction always has an IR tunnel.  The 
type of the P2MP tunnel is defined by one of the other bits.  Is that right?

If so, are all the other bits valid (always)?  The text already says that 
0x00/0x06 are invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 
0x0A (Assisted-Replication Tunnel [draft-ietf-bess-evpn-optimized-ir])?

How can you be sure that any other type besides 0x00/0x06 will be ok?



…
> > M8.4. What is 0x7F reserved for?  It doesn’t seem to be used in this 
> > document.  Why
> > a different registration procedure?
>
> 0x7F just replaces 0x0F - i.e.  No new registration procedure

0x0F is currently Unassigned, not Reserved.


…
> > P17. The 'Updates: ' line in the draft header should list only the 
> > _numbers_ of the
> > RFCs which will be updated by this document (if approved); it should not 
> > include the
> > word 'RFC' in the list.
>
> Done. Also added 6514 to the list.

Hmm...  I don’t see how this document Updates rfc6514….??

But if it does, you need to include some text about it in both the Abstract and 
the Introduction.  BTW, please add something about the Update to rfc7385 in the 
Introduction.


> > P18. There is no reference to rfc5226.
>
> Done.

This one must be Normative.

Re: [bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT)

[Alvaro Retana (aretana)]

On 5/11/17, 1:19 AM, "Adam Roach"  wrote:

Adam:

Hi!

> --
> DISCUSS:
> --
>
> Looking at the Shepherd write up and the Ballot, I see no mention of the
> normative reference to RFC 7348, which is informational and part of the
> Independent Submission stream. As I mention in my comments below, I can't
> fully follow the technical contents of this document, but this seems like
> a red flag to me and -- as far as I can tell -- it hasn't been discussed
> yet. It's possible that the reference just ended up in the wrong section
> (and should actually be informative), but it's not immediately obvious on
> a casual examination whether that's true.

This document was originally scheduled for the Apr/27 Telechat, but as a result 
of Alia’s DISCUSS [1], the reference to rfc7348 was changed to Normative.  The 
WG was cc’ed during the discussion, and I then reran the IETF LC with the 
downref explicitly mentioned [2].  I have no concerns about it.

Yes, the Shepherd’s write-up should have been updated.


> --
> COMMENT:
> --
>
> I strongly second Mirja's comment requesting positive confirmation from
> the WG that is is collectively aware of the associated IPR
> declarations.

In my reply to Mirja [3] I pointd out that the WG was made aware of the IPR.

Thanks!

Alvaro.



[1] 
https://mailarchive.ietf.org/arch/msg/bess/Tj-xvbbZRxFegIeowE2bumBJoYU/?qid=1767aa857c5296fdb791b01305084bbb
 
[2] 
https://mailarchive.ietf.org/arch/msg/ietf-announce/LpT4Xp4HWXf44juhTY6_EnC1JBQ/?qid=1767aa857c5296fdb791b01305084bbb
 
[3] 
https://mailarchive.ietf.org/arch/msg/bess/sgYtaqhSC_dlQtVowTB6zZdhlS4/?qid=1767aa857c5296fdb791b01305084bbb
 

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

Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-evpn-vpws-11: (with DISCUSS and COMMENT)

[Alvaro Retana (aretana)]

Sami:

Hi!

Let’s go ahead and add the text to explain the operation with VXLAN – I think 
that the reference to rfc7348 should be Normative.

I’ll take care of dealing with the downref when we’re ready with the new text.

Thanks!

Alvaro.






On 4/12/17, 2:14 PM, "Sami Boutros"  wrote:

Hi Alia,

Please see comments inline.


On 4/11/17, 4:43 PM, "Alia Atlas"  wrote:

>Alia Atlas has entered the following ballot position for
>draft-ietf-bess-evpn-vpws-11: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwICaQ=uilaK90D4TOVoH58JNXRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-rljSFAaM5b76_QaDSTz2BD_8ny0Dxcf4sM=s8oat7vUDx6NHV0vOehUl_fLjsLHsTqmht3xIHoOr2I=
> 
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dvpws_=DwICaQ=uilaK90D4TOVoH58JNXRgQ=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98=78sPNErI-rljSFAaM5b76_QaDSTz2BD_8ny0Dxcf4sM=MlJKXisQTr1aheS8hahty-iFDOCS_GhM37X2lMUAH54=
> 
>
>
>
>--
>DISCUSS:
>--
>
>First, thank you for a clearly written document that contained enough
>context to trigger my hazy
>memory of some of the technical details.
>
>My concern is around this paragraph in the Introduction:
>
>"The MPLS label value in the Ethernet A-D route can be set to the
>   VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may
>have
>   a global scope or local scope per PE and may also be equal to the
>   VPWS service instance identifier set in the Ethernet A-D route.
>"
>
>First, I recognize that folks have implemented and deployed EVPN with
>VXLAN.
>That's fine.  There is an ISE RFC 7348 that describes VXLAN.   Depending
>on what
>you (authors, shepherd, AD, WG) decide to do about the rest of my
>concern, it is
>likely that this should be normative references - which would be a
>downref.

I can add the 7348 as a normative reference.

>
>Second, the paragraph here isn't really adequate to describe how to
>implement the
>functionality.   I don't see how:
>a) The ingress PE decides which VNIs it can send based upon the
>VNI=MPLS_label
>from the egress.   Is there an assumption that VXLAN allows
>sending all VNIs across
>the particular VPWS, whether port-based, VLAN-based, etc?

We are signaling Ethernet A-D route per VPWS instance, and in there we will 
signal 
VNI instead of an MPLS label for VxLAN encap.

>b) Is there an assumption that the egress PE-advertised MPLS label
>also indicates the
> VNI to be used?  

EVPN can work with different encapsulations a BGP Tunnel Encapsulation 
Attribute 
That specifies the tunnel type will be added to the Ethernet A-D route.


>That seems like another mode, like the
>VLAN-based service, except
> it is perhaps VNI + VLAN-based service?

The draft lists clearly the different service interface types, and there will 
be only one VNI per VPWS instance wether this is Vlan or port based.

>
>Please don't take this Discuss as a reason to remove the paragraph and
>the implied functionality.
>If it's implemented and deployed (and I think it is) - then what I really
>want is to just have it
>adequately written down so that others can interoperably implement.  The
>downref to VXLAN
>should just be a matter of process nuisance (i.e. another IETF Last Call
>and handling any concerns).
>

Should I add the 7348 as a normative reference?



>
>--
>COMMENT:
>--
>
>1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or
>"This specification" or...

Will fix.
>
>2) Sec 3.1:  "C  If set to 1, a Control word [RFC4448] MUST be
>present when sending EVPN packets to this PE."
>   Given discussions with IEEE about real MACs starting with 4 and 6 in
>top nibble, adding a statement about it being BCP to include
>   the control word (unless using Entropy Label) would be a good idea.
>
Could you suggest some text? 

Should I submit -12 with the changes?

Thanks,

Sami
>


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

Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-vpws-11: (with COMMENT)

[Alvaro Retana (aretana)]

Hi!

Yes, the WG was made aware of the IPR at the WGLC:

https://mailarchive.ietf.org/arch/msg/bess/I5_GI44221EZJGQGWHVdv0ukbGk/?qid=08649c721ebdb111c215f6854ff0c241
 

Alvaro.




On 4/11/17, 12:34 PM, "Mirja Kühlewind"  wrote:

--
COMMENT:
--

The shepherd write-up says:
"Two IPR discussions from Juniper & Cisco respectively:
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-vpws
Haven't seen WG discussion on that."
Can we confirm that the wg is aware of the IPRs before publication?



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

[bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

Dear authors:

I just finished reading this document.  In general, the document could benefit 
from an editorial pass to improve readability; I put in some suggestions below, 
but I’m sure I didn’t mention all.  I don’t think that my comments (even the 
Major ones) will be hard to resolve – most are around providing clarity and 
consistency.  I’ll wait for a revised draft before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Both the Introduction and the Abstract mention that “this document 
discusses how the functional requirements for E-Tree service can be easily 
met…”  It seems to me that RFC7387 is used as the building block for this 
document.  Why is it not a Normative reference?


M2. There is no reference to E-Tree.  Please add a Normative one.


M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): “…then a single 
RT per EVI MAY be used…”  I think that “MAY” is out of place because it seems 
to be expressing just a fact.  Also, please keep the normative language where 
the operation is defined (in this case in 3.1).


M4. Section 3.1 (Known Unicast Traffic) talks about how in the “multi-homing 
scenario of section 2.2…the PE MAY advertise leaf indication along with the 
Ethernet A-D per EVI route”.  Given that the text later says that “in case of 
discrepancy, the multi-homing for that pair of PEs is assumed to be in default 
"root" mode”, I find the “MAY” not sufficient.  If we want to prevent as many 
discrepancies as possible, shouldn’t that be a “SHOULD” (or even a “MUST”)?   
Given the local configuration, why would the PE not want to include the leaf 
indication…ever…?


M5. In Section 5.1 (E-TREE Extended Community) there is redundant information 
(first and last paragraphs).  Among that redundant information there is no 
consistency: “the Leaf Label field is set to a valid MPLS label” and “the Leaf 
Label MUST be set to a valid MPLS label” – please be consistent and specify 
things just once.

M5.1. BTW, that is a “valid MPLS label”?  How would a receiver recognize it?  
Please add a reference to avoid confusion.


M6. Definition of the E-TREE Extended Community

M6.1. Only one Flag is defined.  What about the others?  Please set up a 
registry.

M6.2. [Minor] Please put a Figure number and heading for the community format.

M6.3. It looks like the Reserved fields are set to 0.  What should happen if 
the receiver gets something else?

M6.4. “…the Leaf-Indication flag MUST be set to one and Leaf Label is set to 
zero. The received PE should ignore Leaf Label and only processes 
Leaf-Indication flag.”  What if the Leaf Label is not set to zero?  The second 
sentence says to ignore it, but the first one that it “MUST be…set to zero”.  
Which one is it?  Maybe both…  Be specific!

M6.5. “…the Leaf Label MUST be set to a valid MPLS label and the 
Leaf-Indication flag should be set to zero. The received PE should ignore the 
Leaf-Indication flag.”  Similar question for the Leaf-Indication bit.

M6.6. “A non-valid MPLS label when sent along with the Ethernet A-D per ES 
route, should be logged as an error.”  I’m assuming that not only the logging 
is needed, but is the route ignored/discarded too?


M7. The PMSI Tunnel Attribute:  Please be clear to the fact that the C bit is 
being defined/introduced in this document (and not just start talking about it 
as if it is well-known to every reader).

M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says that 
“the high-order bit of the tunnel type field (C bit - Composite tunnel bit) is 
set while the remaining low-order seven bits indicate the tunnel type as 
before.”   But 3.3.1 says that the “new composite tunnel type is advertised by 
the root PE to simultaneously indicate a P2MP tunnel in transmit direction and 
an ingress-replication tunnel in the receive direction…”.  Knowing, from 5.2 
that when the C bit is set “Tunnel Types…0x06 'Ingress Replication' is 
invalid”, then does the C bit have a set meaning or ???   [BTW, s/is/are]

M7.2. [Minor] In some places you talk about the “C bit” or “Composite tunnel 
bit”, but later mention the “Composite flag”.  I’m assuming it is the same 
thing – please be consistent!

M7.3. “invalid tunnel type”  RFC6514 talks about an “undefined tunnel type”.  
Do you mean the same thing?  If you do, please use the right terminology and 
put a reference to rfc6514 here to remind people where the action is defined.


M8. Section 8.1 (Considerations for PMSI Tunnel Types).

M8.1. What should the name of the bit be?  C bit, “composite tunnels” or 
“Composite tunnel bit” – all 3 versions are used, and IANA will want specific 
directions.

M8.2. “…by removing the entries for 0xFB-0xFE and 0x0F”  The range between 
0x80-0xFA also needs to be changed/updated.  s/0x0F/0xFF.  It may be clearer to 
write that this document updates the range 0x80-0xFF.

M8.3. “…and replacing them by…”   Please format the table so that spacing is 
aligned (for better clarity for IANA).  Also, 

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Alvaro Retana (aretana)]

One more thing…you’re missing the reference to RFC5226.

Thanks!

Alvaro.

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Alvaro Retana (aretana)]

On 2/3/17, 4:41 PM, "Sami Boutros"  wrote:

[Oops…sent the last two too early… ☹ ]
 
Sami:

Hi

> Thanks for your review. Please have a look at attached draft w/ most of the 
> comments 
> addressed.
 
Looking at the published version -08.
 
I have some answers to your answers below.  I also see that there may be other 
changes as a result of the discussion on this thread.  I’ll wait for an update 
before starting the IETF Last Call.
 
Thanks!
 
Alvaro.
 
 
…
 
> > M4. Section 1.2 is titled Requirements.  However, the list seems to include 
> > a combination of 
> > statements of fact (“EPL service access circuit maps to the whole Ethernet 
> > port”: this is pretty 
> > much the definition of EPL), solution-sounding lines (“Each VLAN 
> > individually (or  > VLAN> combination) will be considered to be an endpoint for an EVPL 
> > service”: not only does it 
> > sound like what the solution will do, but it is also the definition of 
> > EVPL), and statements that 
> > talk to the configuration and not what the technical solution described 
> > later can do (“A given 
> > PE could have thousands of EVPLs configured. It must be possible to 
> > configure multiple EVPL 
> > services within the same EVI.”: is there an actual scalability 
> > requirement?). I would have 
> > expected actual requirements (for example: “EPL service access circuits 
> > MUST map to the whole 
> > Ethernet port”; normative language is not required) that I can then check 
> > against the solution – 
> > but it all sounds like a rehash of what was explained before.  ☹
> 
> Sami: Please have a look at the attached draft to see if you are OK with the 
> section now, we can 
> consider removing the section too.
 
The new text is not necessarily better – the normative language added doesn’t 
always do what it should, for example: “A given PE MAY have thousands of EVPLs 
configured.”  That is really still a statement, not an option (“MAY”) given as 
part of the solution.
 
Yes, please remove this section.
 

… 
> > M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS 
> > service instance identifier” 
> > How should this be aligned into the larger field?
> 
> Sami: Changed the text to "This document specifies the use of the per EVI 
> Ethernet A-D route to 
> signal VPWS services. The Ethernet Segment Identifier field is set to the 
> customer ES and the 
> Ethernet Tag ID 32-bit field MUST be set to the 24-bit VPWS service instance 
> identifier value."
 
Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 
32-bit field.  I’m guessing there will be some 0-padding, but will that the at 
the beginning or the end?
 

… 
> > M6.2. How should the other flags in the Control Flags field be assigned?  
> > Please define a new 
> > registry and include the details in the IANA Considerations section.
> 
> Sami: We are already describing how the other control flags be assigned in 
> the doc, we have 2 
> other Flags B and C, not sure why do we need a new registry?
 
The Control Flags field is 16 bits long, you’re only defining 3 bits.    If 
someone else in the future wants to use one of those other bits, what should be 
the criteria for assignment: first come first served, do you think they should 
at least have an RFC, should that be standards track??  
 
As it is right now, IANA won’t know what to do if anyone else wants do use any 
of the other bits in the future.
 
Note that MBZ doesn’t preclude the bits being used in the future for something 
else.
 
 
> > M6.3. What should a remote PE do if it receives both the P and B flags set 
> > (or both unset)?  I 
> > know that in a single-active scenario they should not be on at the same 
> > time…but what should the 
> > receiver do?
> 
> Sami:  Added "In multihoming scenarios, both B and P flags MUST not be both 
> set or both unset by 
> a sender PE, and a receiving PE that receives an update with both B and P 
> flags set or unset MUST 
> not forward any traffic to the sender PE.”  Need to review this with other 
> authors too.
 
Not forwarding any traffic means that the route is ignored and not used, right? 
 Should it be discarded?  Maybe phrase the resulting action in terms of the 
route and not the forwarding of traffic…
 
… 
> > M6.5. What units is the MTU in?  How is it encoded?
> 
> Sami: Added "L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating 
> the MTU in octets”
 
Yes, but what are the units?  0x0001 means what?  I would assume bytes, but 
please be specific. 
 

… 
> > P1. Please add a reference for VPWS.
> 
> Sami: You mean PWE3 reference?
 
No, VPWS.  I think rfc4664 is called out at some point – please reference it 
when VPWS is first mentioned in the Introduction.
 
BTW, please move it to Informative to avoid a downref.
 
 
> > P2. The [MEF] reference didn’t work for me; on all tries the connection 
> > timed out.  Is it possible to > > find a more stable reference?
> 
> Sami: No 

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Alvaro Retana (aretana)]

On 2/16/17, 3:57 PM, "Alvaro Retana (aretana)" 
<aret...@cisco.com<mailto:aret...@cisco.com>> wrote:


On 2/3/17, 4:41 PM, "Sami Boutros" <sbout...@vmware.com> wrote:



> Thanks for your review. Please have a look at attached draft w/ most of the 
> comments

> addressed.



Looking at the published version -08.



I have some answers to your answers below.  I also see that there may be other 
changes as a result of the discussion on this thread.  I’ll wait for an update 
before starting the IETF Last Call.



Thanks!



Alvaro.





…



> > M4. Section 1.2 is titled Requirements.  However, the list seems to include 
> > a combination of

> > statements of fact (“EPL service access circuit maps to the whole Ethernet 
> > port”: this is pretty

> > much the definition of EPL), solution-sounding lines (“Each VLAN 
> > individually (or <S-VLAN,C-

> > VLAN> combination) will be considered to be an endpoint for an EVPL 
> > service”: not only does it

> > sound like what the solution will do, but it is also the definition of 
> > EVPL), and statements that

> > talk to the configuration and not what the technical solution described 
> > later can do (“A given

> > PE could have thousands of EVPLs configured. It must be possible to 
> > configure multiple EVPL

> > services within the same EVI.”: is there an actual scalability 
> > requirement?). I would have

> > expected actual requirements (for example: “EPL service access circuits 
> > MUST map to the whole

> > Ethernet port”; normative language is not required) that I can then check 
> > against the solution – but it all sounds like a rehash of what was 
> > explained before.  ☹



Sami: Please have a look at the attached draft to see if you are OK with the 
section now, we can consider removing the section too.



[a] the new text is not necessarily better – the normative language added 
doesn’t always do what it should, for example: “A given PE MAY have thousands 
of EVPLs configured.”  That is really still a statement, not an option (“MAY”) 
given as part of the solution.



Yes, please remove this section.





M5. Section 3. (BGP Extensions) says that “This document proposes the use of 
the per EVI Ethernet A-D route to signal VPWS services. The Ethernet Segment 
Identifier field is set to the customer ES and the Ethernet Tag ID 32-bit field 
is set to the 24-bit VPWS service instance identifier.”  First of all [this is 
minor/a nit], if this document intends to be in the Standards Track then it is 
past the “proposing” phase, it is *specifying*.  As a specification, it is 
rather weak in some places; for example, RFC7432 says (as an example) that the 
“Ethernet Tag ID in all EVPN routes MUST be set to 0”: that is a strong 
statement of what is expected.  On the other hand, this document is modifying 
the behavior, but no Normative language is used.  [In general I don’t advocate 
for the use of Normative language everywhere, but in cases like this where the 
behavior is being changed from the base spec when using this extension, it 
seems necessary.]



M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS 
service instance identifier” How should this be aligned into the larger field?



Sami: Changed the text to "This document specifies the use of the per EVI 
Ethernet A-D route to signal VPWS services. The Ethernet Segment Identifier 
field is set to the customer ES and the Ethernet Tag ID 32-bit field MUST be 
set to the 24-bit VPWS service instance identifier value."



[a] Ok, but you still didn’t mention how the 24-bit value is to be aligned in 
the 32-bit field.  I’m guessing there will be some 0-padding, but will that the 
at the beginning or the end?





M6. Section 3.1 (EVPN Layer 2 attributes extended community).



M6.1. For the P flag – “SHOULD be set to 1 for multihoming all-active 
scenarios”: in a multihoming all-active scenario, when would this flag not be 
set?  IOW, why is the “SHOULD” not a “MUST”.  A couple of paragraphs later: 
“…the PEs in the ES that are active and ready to forward traffic to/from the CE 
will set the P bit to 1”.  In the all-active scenario, is there a case where a 
PE would not be “active and ready”?  What does that mean?  Clarifying may 
justify the “SHOULD”.



Sami: changed the text to "MUST be set to 1 for multihoming all-active 
scenarios by  all active PE(s)."



M6.2. How should the other flags in the Control Flags field be assigned?  
Please define a new registry and include the details in the IANA Considerations 
section.



Sami: We are already describing how the other control flags be assigned in the 
doc, we have 2 other Flags B and C, not sure why do we need a new registry?



[a] The Control Flags field is 16 bits long, you’re only defining 3 bits.If 
someone else i

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Alvaro Retana (aretana)]

On 2/3/17, 4:41 PM, "Sami Boutros"  wrote:



> Thanks for your review. Please have a look at attached draft w/ most of the 
> comments

> addressed.



Looking at the published version -08.



I have some answers to your answers below.  I also see that there may be other 
changes as a result of the discussion on this thread.  I’ll wait for an update 
before starting the IETF Last Call.



Thanks!



Alvaro.





…



> > M4. Section 1.2 is titled Requirements.  However, the list seems to include 
> > a combination of

> > statements of fact (“EPL service access circuit maps to the whole Ethernet 
> > port”: this is pretty

> > much the definition of EPL), solution-sounding lines (“Each VLAN 
> > individually (or  > VLAN> combination) will be considered to be an endpoint for an EVPL 
> > service”: not only does it

> > sound like what the solution will do, but it is also the definition of 
> > EVPL), and statements that

> > talk to the configuration and not what the technical solution described 
> > later can do (“A given

> > PE could have thousands of EVPLs configured. It must be possible to 
> > configure multiple EVPL

> > services within the same EVI.”: is there an actual scalability 
> > requirement?). I would have

> > expected actual requirements (for example: “EPL service access circuits 
> > MUST map to the whole

> > Ethernet port”; normative language is not required) that I can then check 
> > against the solution – but it all sounds like a rehash of what was 
> > explained before.  ☹



Sami: Please have a look at the attached draft to see if you are OK with the 
section now, we can consider removing the section too.



[a] the new text is not necessarily better – the normative language added 
doesn’t always do what it should, for example: “A given PE MAY have thousands 
of EVPLs configured.”  That is really still a statement, not an option (“MAY”) 
given as part of the solution.



Yes, please remove this section.





M5. Section 3. (BGP Extensions) says that “This document proposes the use of 
the per EVI Ethernet A-D route to signal VPWS services. The Ethernet Segment 
Identifier field is set to the customer ES and the Ethernet Tag ID 32-bit field 
is set to the 24-bit VPWS service instance identifier.”  First of all [this is 
minor/a nit], if this document intends to be in the Standards Track then it is 
past the “proposing” phase, it is *specifying*.  As a specification, it is 
rather weak in some places; for example, RFC7432 says (as an example) that the 
“Ethernet Tag ID in all EVPN routes MUST be set to 0”: that is a strong 
statement of what is expected.  On the other hand, this document is modifying 
the behavior, but no Normative language is used.  [In general I don’t advocate 
for the use of Normative language everywhere, but in cases like this where the 
behavior is being changed from the base spec when using this extension, it 
seems necessary.]



M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS 
service instance identifier” How should this be aligned into the larger field?



Sami: Changed the text to "This document specifies the use of the per EVI 
Ethernet A-D route to signal VPWS services. The Ethernet Segment Identifier 
field is set to the customer ES and the Ethernet Tag ID 32-bit field MUST be 
set to the 24-bit VPWS service instance identifier value."



[a] Ok, but you still didn’t mention how the 24-bit value is to be aligned in 
the 32-bit field.  I’m guessing there will be some 0-padding, but will that the 
at the beginning or the end?





M6. Section 3.1 (EVPN Layer 2 attributes extended community).



M6.1. For the P flag – “SHOULD be set to 1 for multihoming all-active 
scenarios”: in a multihoming all-active scenario, when would this flag not be 
set?  IOW, why is the “SHOULD” not a “MUST”.  A couple of paragraphs later: 
“…the PEs in the ES that are active and ready to forward traffic to/from the CE 
will set the P bit to 1”.  In the all-active scenario, is there a case where a 
PE would not be “active and ready”?  What does that mean?  Clarifying may 
justify the “SHOULD”.



Sami: changed the text to "MUST be set to 1 for multihoming all-active 
scenarios by  all active PE(s)."



M6.2. How should the other flags in the Control Flags field be assigned?  
Please define a new registry and include the details in the IANA Considerations 
section.



Sami: We are already describing how the other control flags be assigned in the 
doc, we have 2 other Flags B and C, not sure why do we need a new registry?



[a] The Control Flags field is 16 bits long, you’re only defining 3 bits.If 
someone else in the future wants to use one of those other bits, what should be 
the criteria for assignment: first come first served, do you think they should 
at least have an RFC, should that be standards track??



As it is right now, IANA won’t know what to do if anyone else wants do use any 
of the other bits in 

[bess] FW: WG Action: Formed L2VPN Service Model (l2sm)

[Alvaro Retana (aretana)]

FYI…

On 11/4/16, 1:58 PM, "iesg on behalf of The IESG" 
 on behalf of 
iesg-secret...@ietf.org> wrote:

A new IETF WG has been formed in the Operations and Management Area. For
additional information, please contact the Area Directors or the WG
Chairs.

L2VPN Service Model (l2sm)
---
Current status: Proposed WG

Chairs:
  Adrian Farrel >
  Qin Wu >

Assigned Area Director:
  Benoit Claise >

Operations and Management Area Directors:
  Benoit Claise >
  Joel Jaeggli >
Mailing list:
  Address: l...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/l2sm
  Archive: https://mailarchive.ietf.org/arch/browse/l2sm/

Charter: https://datatracker.ietf.org/doc/charter-ietf-l2sm/

The IETF and the industry in general is currently specifying a set of
YANG models for network element and protocol configuration. This is an
essential first step, but the end goal is a full system configuration
that enables service agility to speed service creation and delivery and
allows the deployment of innovative new services across networks.
Services are built from a combination of network element and protocol
configuration, but are specified to service users in more abstract terms.

The Layer Two Virtual Private Network Service Model (L2SM) working group
is a short-lived WG. It is tasked to create a YANG data model that
describes a L2VPN service (a L2VPN customer service model). The model can
be used for communication between customers and network operators, and to
provide input to automated control and configuration applications.

It is recognized that it would be beneficial to have a common base model
that addresses multiple popular L2VPN service types. The working group
will derive a single data model that includes support for the following:
- point-to-point Virtual Private Wire Services (VPWS),
- multipoint Virtual Private LAN services (VPLS) that use LDP-signaled
Pseudowires
- multipoint Virtual Private LAN services (VPLS) that use a Border
Gateway Protocol (BGP) control plane as described in RFC4761 and RFC6624
- Ethernet VPNs specified in RFC 7432.
Other L2VPN service types may be included if there is consensus in the
working group.

It needs to be clearly understood that this L2VPN customer service model
is not an L2VPN configuration model. That is, it does not provide details
for configuring network elements or protocols: that work is expected to
be carried out in other protocol-specific working groups. Instead, the
L2VPN customer service model contains the characteristics of the service
as discussed between the operators and their customers. A separate
process is responsible for mapping this customer service model onto the
protocols and network elements depending on how the network operator
chooses to realise the service.

The deliverable from this working group will provide information that
other working groups can use to evaluate the set of YANG models that they
have already developed or that are under development. This will help them
to identify any missing models or details. Thus, the deliverable can be
viewed as driving requirements for service delivery models so that the
customer service parameters can be mapped into inputs used by the
protocol configuration models.

The working group will learn from the experience of the L3SM working
group and it is expected that the L2SM data model will have similar
structure to the L3SM data model to enable benefits of common code,
provide shared user experience, and leverage discussions that took place
during the L3SM development.

The working group should consider draft-wen-l2sm-l2vpn-service-model as a
starting point.

The working group will coordinate with other working groups responsible
for L2VPN protocol work (most notably with BESS and PALS). It will also
coordinate with other organizations working on related L2VPN data models
(such as the MEF).

Milestones:
  Dec 2016 - Adopt WG draft for data model
  Oct 2017 - Request publication of data model as Standards Track RFC
  Dec 2017 - Close working group



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

[bess] FW: Last Call: (Multicast VPN state damping) to Proposed Standard

[Alvaro Retana (aretana)]

idr and pim WGs:

Hi!

Please take a look at this document and send comments to the bess WG.

The IETF Last Call expires on Apr/13, but the document is scheduled to be
reviewed by the IESG on May/5, so there's enough time to address comments.

Thanks!

Alvaro.

On 3/23/16, 3:18 PM, "iesg-secret...@ietf.org" 
wrote:

>
>The IESG has received a request from the BGP Enabled Services WG (bess)
>to consider the following document:
>- 'Multicast VPN state damping'
>   as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>i...@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be
>sent to i...@ietf.org instead. In either case, please retain the
>beginning of the Subject line to allow automated sorting.
>
>Abstract
>
>
>   This document describes procedures to damp multicast VPN routing
>   state changes and control the effect of the churn due to the
>   multicast dynamicity in customer sites.  The procedures described in
>   this document are applicable to BGP-based multicast VPN and help
>   avoid uncontrolled control plane load increase in the core routing
>   infrastructure.  New procedures are proposed inspired from BGP
>   unicast route damping principles, but adapted to multicast.
>
>
>
>
>
>The file can be obtained via
>https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ballot/
>
>
>No IPR declarations have been submitted directly on this I-D.
>
>

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

Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03

[Alvaro Retana (aretana)]

On 2/24/16, 11:58 AM, "Thomas Morin" 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> wrote:

Thomas:

Hi!

There are several places where we're still not in sync.  Please se below.

Maybe talking in person would be good.

Thanks!

Alvaro.




2016-02-23, Alvaro Retana (aretana):
The Abstract says that the procedures are "inspired from BGP unicast route 
damping".  It seems to me that the intent is in fact to adopt the algorithm 
from RFC2439.  However, the text is not explicit/clear about that.
Saying so would I think actually be a misleading simplification, the reader may 
miss the facts:
- that the proposal is to keep advertising a dampened multicast VPN state up 
(in RFC2439, a dampened route stops being advertised)
- that the document is not BGP-specific but also specifies a mechanism for the 
PIM FSM
- that only exponential decay is borrowed from RFC2439

This last sentence is what I meant above by "adopt the algorithm from RFC2439". 
 In other words, your proposal is to dampen the multicast state using the 
exponential decay algorithm defined in RFC2439, right?

In your response to my detailed comments there are statements that confuse me a 
little…  I put some more comments/questions below.




  1.  As you all know, the history behind BGP damping has not been without it 
being considered useless and even having recommendations (from RIPE, for 
example) not to use it.

A few things are important to have in mind:
- the application context here is not the Internet
- multicast state propagates in a very different fashion
- the damping algorithm techniques is not the same
- the side-effects of damping unicast and damping multicast as proposed here 
are fundamentally different: here damping causes no impact on the service

Overall, I would say that the weaknesses of RFC2439 and the recommendations in 
RFC7196 were well known by co-authors and that we came to the conclusion that 
this multicast VPN would not suffer from similar weaknesses.

How did you arrive at the default and maximum values?

By simulating with simple parameters and choosing conservative low-risk values.
Considering that, by design, whatever the parameters, multicast streams will be 
delivered unchanged and that the only thing you tradeoff against is less 
dynamicity and a possibly slightly increased bandwidth use, the default and 
maximum values do not have to be perfectly tuned.

Please include this type of information (above) in the document.  Given the 
history of dampening in general, understanding the differences considered will 
go a long way and avoid more questions. ;-)


It concerns me that there are no known implementations (from the Shepherd's 
report).
This concern is valid.
See below...

Because of that, I think this document would be better suited as an 
Experimental RFC, with the explicit purpose of gaining experience with the 
values and determine the impact in live deployments (which then could support a 
standard version).  Please consider changing the intended Status.
Let me go back to why this proposal started: some lab testing was done showing 
that it was easy, in the lab, to create significant overload on PE and RRs BGP 
stacks by flapping multicast state at the edge.  Having a standard track to 
provide the appropriate tooling against this DoS risk seems to me as making 
sense.  I think that the proposed procedures are not close enough to the 
solution and problem addressed by RFC2439 to say that RFC2439's history is an 
argument to pass through an Experimental RFC first.

You might be right in this last point (the history of RFC2439 shouldn't affect 
this document), specially given the explanation you gave earlier (where you 
talked about multicast being different, not intended for the Internet, etc.).

However, the rest of your answer (in that last paragraph) points only at 
experience in seeing the problem and testing the solution "in the lab".  Not 
outside the lab.  In other words, the motivation and problem both came from lab 
tests.  Augmented by the fact that there are no implementations it renews my 
proposal to make this document Experimental — as I said before, with the 
explicit purpose of gaining experience: is the problem observed in deployed 
networks, are the conditions there the same/similar as in the lab, are the 
parameters adequate.

Note that I don't think that an RFC has to be in the Standards Track to prove 
useful.


…



  1.  Are you adopting the exponential decay algorithm from RFC2439?  That 
seems to be what's happening because you are not explicitly defining a new 
algorithm, but some of the text leave doubts.  For example:
 *   "inspired from BGP unicast route damping"  I know the application is 
different, but if the algorithm is the same then please say it.

The procedures associated to the exponential decay are different.

Are you referring to the procedures as to when a penalty is incurred (multicas

Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT)

[Alvaro Retana (aretana)]

On 2/28/16, 5:37 PM, "Joel Jaeggli"  wrote:

Joel:

Hi!  How are you?

...
>--
>DISCUSS:
>--
>
>After further discussion related to the ops dir review, I'm going to have
>to echo Benoit and the Opsdir reviewers concern.

I have to say that, as Eric, I am at a loss as to what specifically you
want to see in the document.  Please see my comments below related to the
OpsDir review text.


>--
>COMMENT:
>--
>
>Sue Hares performed the opsdir review. benoit holds the discuss for the
>points she raised.
>
>Status: Not ready,  three major concerns and two editorial nits:
>
>Major concerns:
>
>1)  Specification of the Extranet Source Extended Community and Extra
>Source extended Community

I think the authors took care of this already by making sure that 4.4
includes the text that Sue had proposed [1].

...
>2)  Why is there no Deployment considerations section?

This seems to be the sticking point.  What exactly are you looking for?

Please take a look at Sections 1.2. (Scope) and 1.3. (Clarification on Use
of Route Distinguishers) -- these are maybe not the best named sections,
but in them the authors lay out when this spec is useful: SSM and ASM
deployments (not Dense mode), calls out potential problems with BSR,
applicable to both PIM and BGP signaling, justified the use of a unique
VRF per RD.

Section 1.4. (Overview) gives some examples of potential deployments
("only some of its multicast C-sources be treated as extranet C-sources",
or "some of its extranet C-sources can transmit only to a certain set of
VPNs"), and it talks about the need for the SP to coordinate with the
customer during the provisioning process.

It seems to me that there's already a pretty good summary in those
sections, but they are not called "operational considerations"Š  What is
missing?  Do you want the above to be in a specific titled section, or
maybe there are other details you'd like to see -- if so, what are they?


A couple of days ago you raised a specific point [2]:

"...
there is eleborate discussion of the
requirement for one RD per VRF and then extranet seperation adds a twist
that.

   However, when Extranet Separation is used, some of
   the local-RD routes exported from the VRF will contain the extranet
   RD.  Details concerning the exported routes that contain the extranet
   RD can be found in Sections 4.1 and 7.3.
"

It sounds like you may want more clarity/details on parts of that.  What?



...
>3)  Is security section really a security section? It seems more like
>³do this policy² or this will fail.  It should get a stronger review from
>the security directorate

I am in fact not able to find a SecDir review.  However, the SEC AD did
put a DISCUSS on this document [3] and later cleared it [4] based on added
text.

Are there specific security concerns?

Thanks!

Alvaro.



[1] https://mailarchive.ietf.org/arch/msg/bess/h3H9joH90g2B1XplYi_H9QJaf6k
[2] https://mailarchive.ietf.org/arch/msg/bess/Gg4e8CvN5TpvhqmvUOCB4vRvlug
[3] https://mailarchive.ietf.org/arch/msg/bess/DBdwMh2Z3WE80NJxhA5qDsmlQwI
[4] https://mailarchive.ietf.org/arch/msg/bess/sjxLrpyGCCarO86xd5n617Q3fIk

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

Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)

[Alvaro Retana (aretana)]

Stephen:

Hi!

Xiaohu posted an update that we hope addresses your concerns.  Pelase take
a look.


Thanks!

Alvaro.


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

Re: [bess] Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS)

[Alvaro Retana (aretana)]

Alia:

Hi!

Xiaohu posted an update which I think should address your concerns.  Please 
take a look.

Thanks!

Alvaro.

On 12/2/15, 11:13 PM, "Alia Atlas" 
> wrote:


That works for me.

Thanks,
Alia

On Dec 2, 2015 11:08 PM, "Xuxiaohu" 
> wrote:
Hi Alia,

> -Original Message-
> From: Alia Atlas [mailto:akat...@gmail.com]
> Sent: Thursday, December 03, 2015 11:07 AM
> To: The IESG
> Cc: 
> draft-ietf-bess-virtual-sub...@ietf.org;
>  aret...@cisco.com;
> bess-cha...@ietf.org; 
> martin.vigour...@alcatel-lucent.com;
>  bess@ietf.org
> Subject: Alia Atlas' Discuss on draft-ietf-bess-virtual-subnet-06: (with 
> DISCUSS)
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bess-virtual-subnet-06: 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-virtual-subnet/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for a clear and well-written document.  I have one point that is
> peripheral to most of the draft.
>
> In Section 4.3, it says:
>
>  " In addition, for any other
>applications that generate intra-subnet traffic with TTL set to 1,
>these applications may not work properly in the Virtual Subnet
>context, unless special TTL processing for such context has been
>implemented (e.g., if the source and destination addresses of a
>packet whose TTL is set to 1 belong to the same extended subnet,
>neither ingress nor egress PE routers should decrement the TTL of
>such packet.  Furthermore, the TTL of such packet should not be
>copied into the TTL of the transport tunnel and vice versa)."
>
> The idea of not decrementing TTL is quite concerning.  I can conjecture cases
> where there is a routing loop between the relevant PEs - during reconvergence
> when a host moves from one datacenter to another is a trivial case.
>
> One approach may be to ask why a packet would have a TTL of 1 and determine
> if this case must be resolved.  Another might detecting a loop back to an
> out-of-datacenter PE and dropping the packet.  I'm sure you can develop other
> good ideas and solutions.

How about doing the following text change:

" In addition, for any other
applications that generate intra-subnet traffic with TTL set to 1,
these applications may not work properly in the Virtual Subnet
context, unless special TTL processing and loop-prevention mechanisms for 
such context have been
implemented. Details about such special TTL processing and loop-prevention 
mechanisms are outside the scope of this document."

Best regards,
Xiaohu

>
>

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

Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03

[Alvaro Retana (aretana)]

On 11/17/15, 4:33 PM, "Eric C Rosen"  wrote:

>[Eric]  Alvaro, thanks for your review.  I just posted revision -04,
>with a number of edits made in response to your comments.

Thanks!  I've requested IETF Last Call and put the document on the
Telechat agenda.

Alvaro.

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

[bess] AD Review of draft-ietf-bess-mvpn-extranet-03

[Alvaro Retana (aretana)]

Hi!

I just finished reading this document.

As mentioned by the WG chairs at the meeting in Yokohama, the technology in 
bess can be complex and hard to penetrate for the average (or novice) reader.  
While the target of documents like this one is not always the average (or 
novice) reader, it is important that those readers (including the IESG and 
other review directorates) are able to at least understand what's going on.  
Most of my comments (below) are around readability/clarity.

In general I found the document (relatively) not hard to follow, if you read it 
end-to-end — it may be harder for someone to jump in and read/review a specific 
section without the benefit of building up to it.Because of the length of 
the document, it would be nice to include a "road map" to guide the reader (in 
general: "Section x talks about X, Section y covers Y, etc.").  It might be 
easier to include references to the specific sections in 1.4 (Overview).

This is a long standards track document, so it is bound to have a lot of 
normative language.  On one hand I don't want to go overboard with explicitly 
mandating every little step..but at the same time we want to be clear as to 
what is "actually required for interoperation or to limit behavior which has 
potential for causing harm" [RFC2119].  Due to the potential of bad 
configurations resulting in incomplete/illdefined extranets, I can see why the 
behavior around RTs would require normative language.  However, there are some 
places where the use of rfc2119 keywords may be lacking, not needed or 
inconsistent.  An example of inconsistency is this paragraph from Section 
7.2.3.1. (When Inter-Site Shared Trees Are Used):

   If VRF-S exports a Source Active A-D route that contains C-S in the
   Multicast Source field of its NLRI, and if that VRF also exports a
   UMH-eligible route matching C-S, the Source Active A-D route MUST
   carry at least one RT in common with the UMH-eligible route.  The RT
   must be chosen such that the following condition holds: if VRF-R
   contains an extranet C-receiver allowed by policy to receive extranet
   traffic from C-S, then VRF-R imports both the UMH-eligible route and
   the Source Active A-D route.

.. If the "route MUST carry at least one RT", why isn't the condition to be met 
also normative?  I don't want to belabor on this specific case, it is just an 
example.  However, I would appreciate it if the authors would scan the document 
for required or unneeded normative language.  I pointed at some cases in my 
comments below.

I do have a couple of items that I think are Major (see below) that I would 
like to see addressed before starting the IETF Last Call.






Major:

  1.  Section 1.3. (Clarification on Use of Route Distinguishers) uses the word 
"REQUIREs" in a couple of places.  In a strict manner, the rfc2119 key words is 
"REQUIRED".  While I think that the meaning of using "REQUIREs" should be 
obvious, please rephrase the text to strictly use the rfc2119 language.
  2.  Section 10 (Security Considerations)
 *   What is a "VPN security violation"?  It is mentioned in several 
places, but it is not explicitly defined.  Please either add a reference or be 
clear in what it is.
 *   Misconfiguration is a significant risk, for example assigning the 
wrong RTs to the wrong routes.  I think that risk should be mentioned.

Minor:

  1.  Section 1.1. (Terminology): "We will sometimes say that a route "matches" 
a particular host if the route matches an IP address of the host."  Given the 
previous definition (in the same paragraph) of "match" ("the address prefix of 
the given route is the longest match in that VRF for the given IP address") and 
the use of match there makes it unclear whether you're talking about a host 
route or just the longest match.
  2.  Section 1.3. (Clarification on Use of Route Distinguishers)
 *   This section explains the "unique VRF per RD" condition a couple of 
times — even though the explanation seems to be the same, it would be nice if 
it was explained only once.
 *   ""default RD" (discussed above)"  Where this text appears is in fact 
the first time that a "default RD" is mentioned.  I'm guessing that this refers 
to the RD in the "unique VRF per RD" condition, but please don't make the 
reader guess.
  3.  Section 4.1. (UMH-Eligible Routes)  The "MAY" in the second paragraph 
appears to be part of the example.  Suggested new text:
 *   The UMH-eligible extranet C-source routes do not necessarily have to   
be unicast routes, they MAY be SAFI-129 routes (see Section 5.1.1 of   
[RFC6513]).  If one wants, e.g., a VPN-R C-receiver to be able   to receive 
extranet C-flows from C-sources in VPN-S, but one does not   want any VPN-R 
system to be able to send unicast traffic to those   C-sources, then the 
UMH-eligible routes exported from VPN-S and   imported by VPN-R may be SAFI-129 
routes.  The SAFI-129 routes areused only for UMH determination, but not 

Re: [bess] AD Review of draft-ietf-bess-virtual-subnet-02

[Alvaro Retana (aretana)]

On 11/10/15, 2:18 AM, "Xuxiaohu" 
> wrote:

Xiaohu:

Hi!

We have updated the draft according to your comments and suggestions.

I just have a couple of small items.  Please see my comments below..

I'm going to start the IETF Last Call and put this document up for the IESG 
Telechat on Dec/3.  Please post an update based on the comments below by the 
end of the week.

Thanks!

Alvaro.

. . .
Major:

  1.  The use of rfc2119 keywords is not required.

You left in the rfc2119 boilerplate and reference, please take them off.

...

  1.  You first use "VS" in Section 3.6.  I'm assuming this is related to 
"virtual subnet", but there's no explicit association.

I see that you expanded in 3.6, but now VS is used for the first time in 3.8 
w/out explicitly expanding.

Solution: in 3.6  s/Virtual Subnet/Virtual Subnet (VS)

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

Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover

[Alvaro Retana (aretana)]

bess WG:

As those of you following this thread may have already noticed, no IPR had
been disclosed related to this document, or any of the documents it
replaces ([1] and [2]), at the time this adoption poll started..nor by the
time the poll was to end on Oct/16.

On Oct/17 the WG received a note about IPR found (from one of the
contributors) [3]; the corresponding disclosure was communicated to the WG
on Oct/22 [4].  At the same time a similar disclosure [5] was also
submitted for [2].

It is not uncommon for IPR disclosures to be submitted related to work in
the IETF.  However, it is expected that such disclosures are "made as soon
as reasonably possible after the Contribution is published" [RFC3979].
That clearly did not happen in this case!

Because of the above, and due to authorship and affiliation, the WG Chairs
have decided to recuse themselves from the process of adoption of this
document.  They have asked me to take it on.


I want to then explicitly make the WG aware of the existing IPR claims
related to this document:

https://datatracker.ietf.org/ipr/2696/
https://datatracker.ietf.org/ipr/2697/

Given the recent disclosure, this poll for adoption is extended for
another 2 weeks (ending on November 11, 2015).  Please express your
opinion is support of adoption (or not) on the list.  Even though we
needed to reset the process, please keep in mind from rfc3979:

   It should also be noted that the validity and enforceability of any
   IPR may be challenged for legitimate reasons, and the mere existence
   of an IPR disclosure should not automatically be taken to mean that
   the disclosed IPR is valid or enforceable.  Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies.


To clarify: the IETF (including us as a WG) cannot determine whether the
disclosures are valid, enforceable or even applicable..but you can use
your own criteria when deciding whether to support adoption or not.


Also, with the new IPR baseline, I need all the authors and contributors
to explicitly reply to this message stating whether you know (or not) of
any additional IPR.  [If any of you have already sent such statement to
the WG, there's no need to send it again.]

Thanks!

Alvaro.



[1] https://datatracker.ietf.org/doc/draft-morin-l3vpn-mvpn-fast-failover/
[2] 
https://datatracker.ietf.org/doc/draft-jain-mvpn-bfd-fast-upstream-failover
/
[3] https://mailarchive.ietf.org/arch/msg/bess/uvOZm_K0iKV9btnSK95qVR5wgIk
[4] https://mailarchive.ietf.org/arch/msg/bess/-7TnzEqxfLHqsfFdX6yjHcaVBx8
[5] 
https://www.ietf.org/mail-archive/web/ipr-announce/current/msg01326.html




On 10/2/15, 5:29 AM, "BESS on behalf of Martin Vigoureux"

wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-morin-bess-mvpn-fast-failover [1] as a working group item.
>
>Please send comments to the list and state if you support adoption or
>not (in the later case, please also state the reasons).
>
>This poll runs until the *16th of October*.
>
>Currently there is no IPR disclosed against this document.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to this draft, 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 a document author or contributor* please respond
>to this email and indicate whether or not you are aware of any relevant
>IPR.
>
>The draft will not be adopted until a response has been received from
>each author and contributor.
>
>If you are not listed as an author or contributor, then please
>explicitly respond only if you are aware of any IPR that has not yet
>been disclosed in conformance with IETF rules.
>
>Thank you,
>
>Martin & Thomas
>bess chairs
>
>[1] https://tools.ietf.org/html/draft-morin-bess-mvpn-fast-failover
>
>___
>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] AD Review of draft-ietf-bess-virtual-subnet-02

[Alvaro Retana (aretana)]

Dear authors:

I just finished reading this document.

All of what is described in this document is straight forward, so much so that 
it requires no change to existing technology, which makes me think that 
users/operators have been able to do this all along.  Is that correct?  Is 
there anything special that was missing that this document brings to light?

Being one of several possible solutions for "network virtualization overlays 
within and/or between data centers", I'm wondering about the value of 
publishing what amounts to a set of use cases without even discussing when 
their use would be suitable (declared out of scope).  I reviewed the 
discussions on the lists (l3vpn/bess) and can clearly see why the Shepherd 
characterized the document as "could have been considered controversial".  Had 
I reviewed the document at adoption time I probably would have ended up in the 
rough side of the consensus.  There's obviously no need to revisit the topic of 
what do to with this document since clearly the WG Chairs believe there is 
consensus to publish.

I do have some other comments (below). In general some of the text could be 
made easier to read (see some nits below).  I would like to see my comment 
about rfc2119 language addressed (and an update published) before starting the 
IETF Last Call.

Thanks!

Alvaro.


Major:

  1.  The use of rfc2119 keywords is not required.  Note that in general these 
keywords "MUST only be used where it is actually required for interoperation", 
but you're using them to apparently express requirements w/out specific 
guidance or to restate what is normal network operation .  For example:
 *   In Section 3.3. (CE Host Discovery) the text reads: "PE routers SHOULD 
be able to discover their local CE hosts… PE routers could accomplish local CE 
host discovery by…ARP or ND…LLDP…VDP), or even interaction with the data center 
orchestration system…"  There is no specific mechanism mandated that supports 
the use of "SHOULD".
 *   In Section 3.4. (ARP/ND Proxy): "PE routers SHOULD only respond to an 
ARP request or Neighbor Solicitation (NS) message for a target host when it has 
a best route for that target host in the associated VRF and the outgoing 
interface of that best route is different from the one over which the ARP 
request or NS message is received."  Isn't this how proxy ARP already works?  
Am I missing something that requires the use of "SHOULD" in this document?
 *   Section 4.3. (TTL and Traceroute) describes a limitation and then says 
"…unless special TTL processing for such case has been implemented (e.g., if 
the source and destination addresses…belong to the same extended subnet, 
neither ingress nor egress PE routers SHOULD decrement the TTL…TTL of such 
packet SHOULD NOT be copied into the TTL of the transport…"  In this case the 
rfc2119 keywords are used as part of an example (e.g.)..which doesn't really 
support the use of "SHOULD/SHOULD NOT".  Is the intent to specify this "special 
processing" in this document?  If so, why "SHOULD" and not "MUST"?  Algo, given 
that the text appears in the Limitations section, if you're mandating the 
"special processing" then it wouldn't be a limitation anymore..

Minor:

  1.  I think that RFC4761, 4762, 4659, 5798 and 6513 should be Informational 
references.
  2.  You first use "VS" in Section 3.6.  I'm assuming this is related to 
"virtual subnet", but there's no explicit association.
  3.  Multicast.  Section 3.2. (Multicast) says that for "IP multicast between 
CE hosts of the same virtual subnet, MVPN technologies [RFC6513] could be 
directly used without any change".  I'm assuming that you're not referring to 
link-local multicast (between hosts on the same subnet) because later (Section 
4.2) you say that "link-local multicast traffic cannot be supported".  Please 
clarify in 3.2 what type of multicast you're talking about, and/or which you're 
not.
  4.  Section 4.3. (TTL and Traceroute).  What does this mean: "traceroute 
output would reflect the fact that these two hosts belonging to the same subnet 
are actually connected via an virtual subnet emulated by ARP proxy, rather than 
a normal LAN"?  I think I know, but please be specific in the text.

Nits:

  1.  Section 1. (Introduction)
 *   s/commonly used in those situations/commonly used in situations
 *   There are a couple of very long sentences that could be simplified — 
they make sense, but other reviewers may not capture the essence.  Just a 
suggestion
*   OLD>
*
*   As a result, the traffic from a cloud user (i.e., a VPN user) which
*   is destined for a given server located at one data center
*   location of such extended subnet may arrive at another data
*   center location firstly according to the subnet route, and then
*   be forwarded to the location where the service is actually
*   located.  This suboptimal routing would obviously result in an

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[Alvaro Retana (aretana)]

On 9/30/15, 2:34 AM, "thomas.mo...@orange.com" 
> wrote:

Thomas:

Hi!

. . .
Current:

   The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet 
[I-D.ietf-bess-mvpn-extranet].
  For example, the (C-*,C-*-
   BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
   can optionally share a label.

Proposed:
These specifications do not prevent sharing of labels between P-tunnels, 
such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI 
A-D route originated by a given PE (note that other specs put constraints on 
how that can be done, e.g. 
[I-D.ietf-bess-mvpn-extranet]).


In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don’t even 
mention them — referring to them just causes confusion as to whether they were 
needed.

I think that if this is clearly provided as an example then it can help the 
reader have the right context information to better understand the spec.

That works for me.   Just a nit: s/These specifications/This specification

. . .
Let's use RFC6513 section 2.1.2 as the reference for ingress replication, and 
eventually let the reader find out by himself when/if the IR-replication 
related materiel in this RFC is updated...

Fine with me too.

Thanks!

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

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[Alvaro Retana (aretana)]

On 9/28/15, 10:39 AM, "thomas.mo...@orange.com" 
> wrote:

Jeffrey/Thomas:

Hi!

First of all, please note that the Gen-ART review that came in today had the 
same comment about the Normative references…which really indicates that if you 
want to change them, then (at least) the text needs to be clarified.

2015-09-28, Jeffrey (Zhaohui) Zhang:
Alvaro,
> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative 
> References.
I thought about this further, and would like to keep them both as informational 
for the following reasons.
The extranet draft is referred to in the draft as following:
   … The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet 
[I-D.ietf-bess-mvpn-extranet].
Both extranet and label sharing are optional, not required for implementing the 
procedures in this draft.

I agree with that.
To make it more obvious that this is an informative comment, I think you could 
rewrite as: "These specifications do not prevent sharing of labels between 
P-tunnels (note that other specs put constraints on how that can be done, such 
as 
[I-D.ietf-bess-mvpn-extranet])".

This proposed text changes what seems to be the original intent..if that was 
the goal, then I’m ok with something like it.  In fact, if the rules in 
ietf-bess-mvpn-extranet are not needed then don’t even mention them — referring 
to them just causes confusion as to whether they were needed.




As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though 
there are some problems with RFC 6514's specification of IR P-tunnels, which 
are addressed in detail in draft-ietf-bess-ir.



Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VPN 
customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, but it 
doesn't really depend on those details specified in draft-ietf-bess-ir. Thus 
draft-ietf-bess-ir should not be a normative reference for it.

The text says this:  "This document describes how the MP2MP tunnel can be 
simulated with a mesh of P2MP tunnels, each of which is instantiated by Ingress 
Replication [I-D.ietf-bess-ir].”  What you say above is that the reference here 
should be RFC6514, is that right?


Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depends 
on Normatively, we might as well avoid mentioning it; making it a Normative ref 
would not buy much (but would delay publication until draft-ietf-bess-ir is 
published).

It has to be Normative it the functionality depends on it (see me question 
above).  There’s no way around that.

Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 (if 
approved!) doesn’t mean anything at this point because the functionality that 
this document relies on (??) is not in those RFCs, or in any other RFC that 
updates them.

If the functionality in I-D.ietf-bess-ir is not needed, then just change the 
reference above.

Since its helpful to remind the reader of its existence, I would think it's 
good to keep it, and Informative is fine.

Why?  If the functionality in I-D.ietf-bess-ir is not needed, then just don’t 
mention it at all.

Thanks!

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

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[Alvaro Retana (aretana)]

On 9/25/15, 2:11 PM, "Jeffrey (Zhaohui) Zhang" 
> wrote:

Jeffrey:

Hi!

. . .
Major:

  1.  I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative 
References.
Zzh> Done.

I-D.ietf-bess-ir wasn’t moved.

. . .

  1.  Section 4. (Security Considerations)  Are there really no security 
considerations?

 *   Section 3.1. (Control State)   Says that: "To speed up convergence…PEy 
MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream 
PE…With that, it will receive traffic from all PEs, but some will arrive with 
the label corresponding to its choice of Upstream PE while some will arrive 
with a different label, and the traffic in the latter case will be discarded.”  
I’m assuming that all the traffic (specially the discarded one) belongs to the 
same VPN, so there’s no danger of leaking information, right?  It might be 
worth including something in the Security Consideration so that it’s easier for 
the readers (Security Directorate, for example) to grasp the context.
Zzh> There is indeed no new issues. The quoted text refers to the possible 
arrival of duplication for the same flow that the receiving PEs need to 
receive, and they will be discarded anyway. There is no deliver of duplication 
to CEs, and certainly there is no leaking. I am not sure if that needs to be 
called out.

You don’t have to..but saying that there are no issues usually raises a flag 
for more thorough review by the SecDir/ADs.  You can leave it as is and address 
any issues that may come up later.

Thanks!

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

[bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[Alvaro Retana (aretana)]

Hi!

I just finished reading this document.  In general I think that there are some 
things that could be done to improve the readability/clarity.

While the authors address the items below, I’ll start he IETF Last Call and put 
the document on the IESG Agenda (probably for Oct/15).  Please post an update 
before Oct/8.

Thanks!

Alvaro.


Major:

  1.  I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative 
References.

Minor:

  1.  Update to rfc6514:  Please include a short paragraph (or a couple of 
sentences) explaining how this document updates rfc6514 (maybe in the 
Introduction).
  2.  Even though the text says that terminology is somewhere else, please 
expand the acronyms on first use.  Also, some of the text ("C-G-BIDIR refers to 
a C-G where G is a Bidir-PIM group”, for example) may not be accesible to the 
average reader, even if extensions are in place — you already included some 
background in the Introduction  and I’m not sure we want to rehash everything 
again..just something to think about.  You might want to refer to the RFC 
Editor’s list of well known abbreviations: 
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
  3.  I think there are some references missing, for example: "Bidir-PIM, or 
via MP2MP mLDP”
  4.  Section 3.1. (Control State):
 *   What do you mean by "just like how any other S-PMSI A-D routes are 
triggered”?  I’m thinking that at least a reference is needed.  Later is the 
same paragraph you include an example as well.  Please clarify what you’re 
referring to.
 *   Do we really need this text 3 times in the section?  "The label may be 
shared with other P-tunnels, subject to the anti-ambiguity rules for extranet 
[I-D.ietf-bess-mvpn-extranet].  For example, the (C-*,C-*-BIDIR) and 
(C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally share 
a label."
 *   The paragraphs that start with "The encoding of the Leaf A-D route…” 
are also duplicates.
  5.  Section 4. (Security Considerations)  Are there really no security 
considerations?
 *   Section 3.1. (Control State)   Says that: "To speed up convergence…PEy 
MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream 
PE…With that, it will receive traffic from all PEs, but some will arrive with 
the label corresponding to its choice of Upstream PE while some will arrive 
with a different label, and the traffic in the latter case will be discarded.”  
I’m assuming that all the traffic (specially the discarded one) belongs to the 
same VPN, so there’s no danger of leaking information, right?  It might be 
worth including something in the Security Consideration so that it’s easier for 
the readers (Security Directorate, for example) to grasp the context.

Nits:

  1.  Abstract  s/These specifications/This specification
  2.  s/wrt/with regards to
  3.  Introduction: s/Ingress Replication,this/Ingress Replication this
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] AD Review of draft-ietf-bess-spbm-evpn

[Alvaro Retana (aretana)]

Hi!

I think the general readability of the document could improve.  See below for 
some suggestions.  While that is not a showstopper, I would like to see my 
comments about the Security Considerations (see below) addressed before 
starting the IETF Last Call.

Thanks!

Alvaro.


Major:

  1.  Security Considerations.
 *   The first two paragraphs talk about incorrectly connecting islands 
together, due to misconfiguration (in what looks like two different causes).  
While probably nothing can be done from the EVPN core point of view, it would 
be a good idea to recommend potential actions to be taken to prevent further 
problems; for example, you already say that the identifiers are only policed 
in the SPBM domains” — maybe try rewording that as a recommendation (“care 
should be taken at the SPBM domains, etc.”).  This is important because the 
privacy of the users information could be compromised if the frames are 
delivered to the wrong place.
 *   The last paragraph says “most of the issues”.  What issues are not 
reflected in rfc4761?
 *   What about considerations related to other pieces of the solution?  
Why aren’t they mentioned?  Are they covered somewhere else?

Minor:

  1.  Please expand EVPN and ECT.  PBB (and other acronyms) are in the list of 
well-known abbreviations.  I know that there is a Terminology section, but we 
still should expand of first use specially in the Abstract/Introduction and 
Tittle.  BTW, ECT is not listed in the Terminology. 
[https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt]
 *   There’s a mixture of acronyms that are defined in-line (e.g.  
Shortest Path Source ID (SPSourceID)”), acronyms not defined (DA), expansions 
used without the acronym (e.g. designated forwarder”) and a whole slew of 
others where the reader is expected to check the Terminology section out.  It 
would be nice if there was some consistency in the treatment.
  2.  The References need to be re-formatted.  One case (for rfc7432) it is 
referenced as IETF work in progress”.
  3.  Section 4.8 says that multicast support is not addressed.  However, 
Section 5.1 talks about multicast.

Nits:

  1.  Introduction  s/permit both past, current and emerging future 
versions/permit past, current and emerging future versions
  2.  Section 1.1. Authors  is not needed.
  3.  Section 3
 *   s/to be seamlessly communicate/to seamlessly communicate
 *   The formatting (spacing) needs some work.
 *   Figure 1 is nice, but there’s no text referring to/explaining it.
  4.  IANA considerations.  Use This document has no IANA actions.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Status of draft-ietf-l3vpn-acceptown-community

[Alvaro Retana (aretana)]

[Took Adrian off.]

Hi!

Any ideas on when we might see the update?

Thanks!

Alvaro.

On 2/8/15, 5:50 PM, Adrian Farrel adr...@olddog.co.uk wrote:

Hi authors,

Good news /bad news :-)

The IESG reviewed your document on Thursday on the telechat and approved
it for publication as an RFC. Well done.

However, there are a few minor bits and pieces that need to be tidied up.
You can see it all in the datatracker at
https://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/ball
ot/

 It's a little more than I like to put in an RFC Editor note, so I've
marked the I-D as Revised I-D needed.

As soon as you post a revision, I'll pass it on to the RFC Editor.

Please shout if you have any trouble working out what to do with the
various comments.

Thanks for all the work.

Adrian

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