Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Warren Kumari]

On Fri, Oct 06, 2023 at 3:53 PM, Jorge Rabadan 
wrote:

> Hi Warren,
>
>
>
> Thank you for reviewing.
>
>
>
> We published version 12, which hopefully addresses most of the comments
> and discuss.
>
>
>
> About why two algorithms:
>
>
>
> Initially only highest-preference was defined and implemented, however,
> there was feedback from the Shepherd and others in the WG that defining the
> Lowest-Preference algorithm would provide more flexibility for the
> operator. For instance, the operator could define the same preference value
> for two Ethernet Segments in a PE1, but, by using highest-preference in ES1
> and lowest-preference in ES2, we could achieve different DF election
> results per Ethernet Segmen and therefore have some DF distribution.
>


Urgh, that sounds very much like creeping featurism, but if the WG has
consensus that the additional complexity is worth the win, then ¯\_(ツ)_/¯.

I hadn't considered the "if you set one high and one low you get DF
distribution" aspect, nor did I see this explained in the doc (but perhaps
I missed it).

It seems like it would be *mush* less confusing to just set the priorities
how you want them, but…

It still all seems like needless additional operational complexity, but, if
the WG has consensus on this, I'll clear…

W



>
> Other than that, there is no difference between both, they are
> functionally equivalent. Only that one selects the highest value, and the
> other the lowest one.
>
>
>
> Since the algorithm itself is signaled in the ES routes, and we explain
> how inconsistencies among PEs are handled, we think there is no additional
> complexity or risks.
>
>
>
> If the above explanation is not enough, could you suggest any kind of text
> or guidance that could help clear your DISCUSS?
>
>
>
> Thank you!
>
> Jorge
>
>
>
>
>
> *From: *Warren Kumari via Datatracker 
> *Date: *Monday, August 7, 2023 at 3:55 PM
> *To: *The IESG 
> *Cc: *draft-ietf-bess-evpn-pref...@ietf.org  ietf.org>, bess-cha...@ietf.org , bess@ietf.org <
> bess@ietf.org>, Stephane Litkowski , slitkows.
> i...@gmail.com 
> *Subject: *Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11:
> (with DISCUSS and COMMENT)
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URLnok.it/ext for additional
> information.
>
>
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-pref-df-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://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/
>
>
>
> --
> DISCUSS:
> --
>
> Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
> This seems operationally dangerous and will lead to additional operational
> complexity, tricky to debug behaviors, additional implementation
> complexity,
> etc. Assuming that there *is* a good reason (and "Well, we couldn't
> decide,,
> so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators
> decide
> which algorithm they should deploy, and the pro's and con's of each.
>
> [0]: I did try and find this, but the closest I got was a note in the
> Shepherd
> Writeup saying: "There was a "last minute" agreement on managing the
> highest/lowest pref algorithm using different DF algs rather than a single
> one+local configs." -- this doesn't actually answer the question.
>
>
> --
> COMMENT:
> --
>
> I support John Scudder's DISCUSS, as well as his comments -- the
> Introduction
> seems quite incomplete, and just sort of throws the reader into the deep
> end.
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Warren Kumari's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-13: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-13: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

Thank you for this document, and for working to address Menachem Dodge's OpsDir
review (
https://datatracker.ietf.org/doc/review-ietf-bess-mvpn-evpn-aggregation-label-10-opsdir-lc-dodge-2023-07-02/
)



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-bgp-sdwan-usage-15: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-15: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



--
COMMENT:
--

I am balloting NoObjection, but am quite uncomfortable with it -- I will steal
some of Eric V's ballot text - "... I find it ***weak*** on several points (see
below) and more accurate language will be welcome rather than hand waving. I
strongly suggest that the authors/WG have a second pass on the document."

The document is very hand-wavey, and, based on the number of open comments and
nits, does not appear to have had significant detailed review; I almost
balloted DISCUSS because of this.

This document would benefit from copy-editing.

1: The document opens with: "Here are some of the main characteristics of
"SD-WAN" networks: [...]"
 -- I don't really think that most of these are "the main characteristics of
 "SD-WAN" networks" - e.g: "Instead of all traffic hauled to Corporate HQ for
 centralized policy control, direct Internet breakout from remote branch
 offices is allowed." - this is a characteristic of many many different
 technologies and VPN solutions. The implication of this sentence so early in
 the document is that a: these are differentiating characteristics, and b: that
 they are the **main** characteristics.

2: Editorial: "Instead of all traffic hauled to Corporate HQ for centralized
policy control, direct Internet breakout from remote branch offices is
allowed." - "Instead of hauling all traffic to ..." or "Instead of having all
traffic hauled to..." or...

3: "Some traffic can be forwarded by edge nodes, based on their application
identifiers instead of destination IP addresses, by placing the traffic onto
specific overlay paths based on the application-specific policies." - the
subject of this sentence is very unclear. What is this "some traffic" (why not
all? what does "some" do in this sentence?). Same for "their" in "their
application identifiers".

4: "CPE-Based VPN: Virtual Private Secure network formed among CPEs. This
differentiates from more commonly used PE-based VPNs". How does "VPN" expand to
"Virtual Private Secure network"? **How** this this "differentiates" from more
commonly used PE-based VPNs? ("This differs from more commonly used PE-based
VPNs as it is formed between CPE" would sort of work, but it is still very
unclear *why* this is being noted.

5: "SD-WAN: Software Defined Wide Area Network is an overlay network ..." -
this is a much better definition than how the document was opened. I suggest
that it be used if you want to introduce what SD-WAN **is**.

6: "Conventions used in this document [...] SD-WAN over Hybrid Networks: SD-WAN
over Hybrid Networks typically have edge nodes... You never actually use that
term - you *do* use Hybrid Underlay (e.g "SD-WAN with Hybrid Underlays") a
bunch of times though.

7: "For multicast packets forwarding" -> "For multicast packet forwarding"



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-pbb-evpn-isid-cmacflush-08: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-pbb-evpn-isid-cmacflush-08: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/



--
COMMENT:
--

I fully agree with Eric's "This is a very specific area of work and the text is
not easy to read for a non expert. I read it, but was somewhat baffled by the
quantity of acronyms and terminology, and to I too relied on Pascal Thubert's
IntDir review
(https://datatracker.ietf.org/doc/review-ietf-bess-pbb-evpn-isid-cmacflush-08-intdir-telechat-thubert-2023-08-07/)
to help choose my position.



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

[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
DISCUSS:
--

Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
This seems operationally dangerous and will lead to additional operational
complexity, tricky to debug behaviors, additional implementation complexity,
etc. Assuming that there *is* a good reason (and "Well, we couldn't decide,,
so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators decide
which algorithm they should deploy, and the pro's and con's of each.

[0]: I did try and find this, but the closest I got was a note in the Shepherd
Writeup saying: "There was a "last minute" agreement on managing the
highest/lowest pref algorithm using different DF algs rather than a single
one+local configs." -- this doesn't actually answer the question.


--
COMMENT:
--

I support John Scudder's DISCUSS, as well as his comments -- the Introduction
seems quite incomplete, and just sort of throws the reader into the deep end.



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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-virtual-eth-segment-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Wed, Jul 05, 2023 at 1:58 PM, Patrice Brissette 
wrote:

> Hi Warren, Paul,
>
> I just submit a v11 version removing that section. I was quite surprise as
> you were about this section. It seems like it came from an old template.
>


… and I've cleared my DISCUSS.

Thank you for addressing it so quickly!
W


> Regards,
> Patrice Brissette
> Distinguished Engineer
> Cisco Systems
>
> On 2023-07-05, 13:38, "Warren Kumari via Datatracker"  <mailto:nore...@ietf.org>> wrote:
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-virtual-eth-segment-10: 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/about/groups/iesg/statements/
> handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/
> statements/handling-ballot-positions/> for more information about how to
> handle DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/
> <https://datatracker.ietf.org/doc/
> draft-ietf-bess-evpn-virtual-eth-segment/>
>
> --
> DISCUSS:
> --
>
> Be ye not afraid - this DISCUSS should be easy to address. Please see
> https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/
> statements/handling-ballot-positions/> for some information on DISCUSS
> ballots
>
> Like Paul Wouters I find Section 9 ("Intellectual Property
> Considerations") troubling, but I'm sufficiently troubled that I feel it
> deserves a DISCUSS. I
> *think* that what the text says is compatible with what is in BCP79 / the
> copyright boilerplate, but: 1: IANAL and 2: if it's exactly the same, why
> is this section here?
>
> If it *not* the same, then I think that this requires some discussions
> with the IETF Trust / lawyers / etc...
>
> I strongly suggest removing it, or, if it is needed for some sort of
> corporate
> / legal reason that it be justified / explained.
>
> --
> COMMENT:
> --
>
> Thank you very much for writing this document.
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-virtual-eth-segment-11: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-virtual-eth-segment-11: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



--
COMMENT:
--

Thank you to the authors for addressing my DISCUSS position so quickly and 
painlessly!


Also, thank you very much for writing this document.



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

[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-virtual-eth-segment-10: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-virtual-eth-segment-10: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



--
DISCUSS:
--

Be ye not afraid - this DISCUSS should be easy to address.
Please see
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for some information on DISCUSS ballots

Like Paul Wouters I find Section 9 ("Intellectual Property Considerations")
troubling, but I'm sufficiently troubled that I feel it deserves a DISCUSS. I
*think* that what the text says is compatible with what is in BCP79 / the
copyright boilerplate, but: 1: IANAL and 2: if it's exactly the same, why is
this section here?

If it *not* the same, then I think that this requires some discussions with the
IETF Trust / lawyers / etc...

I strongly suggest removing it, or, if it is needed for some sort of corporate
/ legal reason that it be justified / explained.


--
COMMENT:
--

Thank you very much for writing this document.



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-lsp-ping-09: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
COMMENT:
--

Like Roman, I support the DISCUSS positions of Jim Guichard and Lars Eggert.

I'd also like to thank Di Ma for the DNS-DIR review.



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

[bess] Warren Kumari's Abstain on draft-ietf-bess-srv6-services-12: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-srv6-services-12: Abstain

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

With the updated text in the Security Considerations in Version 12, I'm
clearing my DISCUSS.

I still don't love this (hence the Abstain), but my disquiet is caused caused
by the security considerations in SRv6, not this document itself.

I'd like to specifically call out and thank Ketan Talaulikar, who did an
outstanding job at communicating, addressing the concerns, and defusing the
situation in general.



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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar 
wrote:

> Hi Warren/All,
>
> This draft specifies broadly two types of BGP Services over SRv6:
>
> A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
> B) Global Internet Services - Sec 5.3, 5.4
>
> As explained by my co-author Robert, the operations and mechanisms for VPN
> services are similar to what we've had with MPLS. I believe we are all on
> the same page on this one based on the discussions between Andrew and
> Robert and that there is no new concern as far as (A).
>

Actually, no, I don't think that we are -- if I, as an attacker, somehow
know that VPN x uses MPLS labels Y, that's interesting, but not
particularly valuable -- because of the "fail closed" nature of MPLS (it's
a different protocol, and needs explicit and intentional action to enable
on an interface)  it's really hard for me to "inject" an MPLS packet and
route it into your network. With SRv6, if the SIDs leak, I can construct a
normal v6 packet and route it towards you. Yes, handwave handwave the RFCs
say that you MUST filter at your edges and that the filtering MUST always
be perfect handwave limited domain handwave -- but it's putting a large
amount of faith in operator perfection.

Also, if I, as an attacker get access to a "server" in the provider network
(noc workstation, billing machine, random admin PC, etc), with MPLS it's
very unlikely to be part of the MPLS domain, but  an SRv6 domain is much
more likely to be "squishy" and more likely to encompass parts of the
"enterprise" type systems.

W


>
> Now (B) does bring in filtering aspects (as mentioned in the security
> considerations) to ensure that the SRv6 block that is meant for use
> internal to the operator's network (i.e. SR domain) does not get
> leaked/advertised out from the default table on the Internet Border Router
> (IBR) over to an eBGP peer. This is similar to the precautions that
> operators take today to prevent their infrastructure addresses from being
> leaked to the Internet. The filters in BGP are also accompanied by ACLs at
> the IBRs to prevent traffic destined for those infrastructure IPs from
> entering into the operator network. This is the same in the case of SRv6 as
> well.
>
> I hope that clarifies and we can update the text to convey these aspects
> better.
>
> Thanks,
> Ketan
>
>
> On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF 
> wrote:
>
>> Hi Robert,
>>
>>
>>
>> 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI  1
>>  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
>>
>>
>>
>> Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with
>> the example in section 6.1 of RFC8950 – which states:
>>
>>
>>
>>
>>
>>The extensions defined in this document may be used as discussed in
>>
>>[RFC5565 <https://datatracker.ietf.org/doc/html/rfc5565>] for the 
>> interconnection of IPv4 islands over an IPv6
>>
>>backbone.  In this application, Address Family Border Routers (AFBRs;
>>
>>as defined in [RFC4925 <https://datatracker.ietf.org/doc/html/rfc4925>]) 
>> advertise IPv4 NLRI in the MP_REACH_NLRI
>>
>>along with an IPv6 next hop.
>>
>>
>>
>>The MP_REACH_NLRI is encoded with:
>>
>>
>>
>>*  AFI = 1
>>
>>
>>
>>*  SAFI = 1
>>
>>
>>
>>*  Length of Next Hop Address field = 16 (or 32)
>>
>>
>>
>>*  Next Hop Address = IPv6 address of the next hop
>>
>>
>>
>>*  NLRI = IPv4 routes
>>
>>
>>
>>During BGP Capability Advertisement, the PE routers would include the
>>
>>following fields in the Capabilities Optional Parameter:
>>
>>
>>
>>*  Capability Code set to "Extended Next Hop Encoding"
>>
>>
>>
>>*  Capability Value containing >
>>   AFI=2>
>>
>>
>>
>> As I say, if you were to remove the references to global and 5.3/5.4
>> which explicitly reference it and bring SAFI 1 into play – there would be
>> far less concern from my side, I can’t speak for anyone else, but that
>> would be my feeling
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Saturday, February 12, 2022 9:37 PM
>> *To:* Andrew - IETF 
>> *Cc:* Warren Kumari ; Bocci, Matthew (Nokia - GB) <
>> matthew.bo...@nokia.com>; draft-ietf-bess-srv6-

Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Warren Kumari]

On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Ron Bonica
> Review result: Not Ready
>
> I am an assigned INT directorate reviewer for
> draft-ietf-bess-srv6-services.txt.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> .
>
> Major issues:
>
> 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field.
> This
> is surprising because MPLS appears nowhere in the forwarding plane. Maybe
> we
> shouldn't advertise an MPLS label?
>
> 2) In Section 3.2.1 the draft says:
>
>   BGP speakers that do not support this specification may misinterpret,
>on the reception of an SRv6-based BGP service route update, the part
>of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
>for MPLS-based services.  Implementations supporting this
>specification SHOULD provide a mechanism to control the advertisement
>of SRv6-based BGP service routes on a per-neighbor and per-service
>basis.  The details of deployment designs and implementation options
>are outside the scope of this document.
>
>
Much thanks to Ron for this OpsDir review -- I'd completely missed the
above points, and they are important to address.

W



> s/BGP speakers that do not support this specification/Legacy BGP
> implementations
>
> It seems that this isn't backwards compatible unless either:
>
> - the SHOULD becomes a MUST
> - the mechanism is described in this document
>
> 3) I concur with Warren Kumari's DISCUSS
>
>
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

The Security Considerations section says: "The service flows between PE routers
using SRv6 SIDs advertised via BGP are expected to be limited within the
trusted SR domain (e.g., within a single AS or between multiple ASes within a
single provider network).  Precaution should be taken to ensure that the BGP
service information (including associated SRv6 SID) advertised via BGP sessions
are limited to peers within this trusted SR domain." This is related to (from
RFC8402): "Therefore, by default, the explicit routing information MUST NOT be
leaked through the boundaries of the administered domain."

However, we all know that BGP leaks happen -- and when they do, the SID’s
contained in the leak will be logged by various systems and hence available to
the public into perpetuity.

While the document states that border filtering should protect against traffic
injection, this does not cover the case of internal compromise. Sure, there is
the argument that once there is an internally compromised system, all bets are
off -- but with this, an attacker that knows the SIDs in e.g inject traffic
into a VPN. This seems to me to significantly expand the attack surface to
include the customer's networks too.

Not only does an operator have to ensure that BGP leaks never occur, they have
to then ensure that at no point can there be any filter lapses at any border
node, and be able to guarantee the security of every device, server and machine
within the domain in order for a secure posture to be maintained. Simply saying
that precautions should be taken to make sure that route leak don't occur, when
the consequences of doing so are a: severe and b: hard to recover from seems to
not really cover it. In addition, it seems that the blast radius from a missing
ACL seems much larger if it allows injections.


--
COMMENT:
--

I'm still reviewing the document, but wanted to get an initial ballot in, so
that we could start discussing it. Hopefully someone can help my understand how
this doesn't expand the consequences of a BGP leak.



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: No Objection

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



--
COMMENT:
--

Much thanks to Scott Bradner for the OpsDir review (-09), discussions and then
re-review of -11. Jeffrey has agreed to change the SHOULD at the ned of S5.3.1
to a MUST (see OpsDir thread), and I'm balloting NoObj with the assumption that
that will happen.

Thanks again to Scott and the authors; I think that the comments since -09 have
noticeably improved the document.



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-datacenter-gateway-11: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-11: No Objection

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 DISCUSS and COMMENT positions.


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



--
COMMENT:
--

I am changing my previous DISCUSS to a No Objection; I was planning on Abstain,
but after yet more thought I think No Objection is the best position.

Background:
When thinking about this document I still feel disquiet (actually
"heebie-jeebies" is probably a better description!), but it's not actually
**this** document which is causing me concern, it is rather RFC8402 (and the
fact that this facilitates /propagates its use).  I still feel like stamping my
feet and throwing all of my toys out the cot, but my grump cannot realistically
be pointed at this draft.

I'd also like to recognize that Adrian Farrel did a great job on talking me
down from my ledge. I was filled with righteous indignation, and his helpful
and friendly tone helped me understand and process my thoughts; this directly
led to my willingness to change. Thank you everyone.



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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)

[Warren Kumari]

On Wed, May 19, 2021 at 4:47 AM Adrian Farrel  wrote:

> Hi Warren,
>
> Thanks for this. I'll try to unpick it.
>
> > DISCUSS:
> > ---
> >
> > I hope that I'm just misunderstanding something obvious, but I strongly
> support
> > John's DISCUSS
>
> So far, so good: we are in discussions with John and believe we will reach
> a resolution that satisfies him.
>
> > when SR was "approved" it was with the understanding that it
> > would only be used within "real" limited domains, and would never be sent
> > outside of closed/limited network.
>
> I fear that there may have been some slipperiness in the discussion that
> led to this understanding.
> I recall pushing back quite a bit on the definition of "SR domain" as it
> appeared in 8402 during IETF last call. But I didn't see a lot of support
> for my view and concluded I was in the rough.
>
> He definition we ended up with specifically allows for tunnelling of SR
> over non-SR parts of the network.


I suspect that part of this is this comes in the use of the term "tunnel"



> And, indeed, the nature of SRv6 is that packets containing the SRH may be
> forwarded "transparently" by non-SR IPv6 routers. The domain is, therefore,
> defined as the collection of interconnected SR-capable nodes. We ended up
> with:
>
>Segment Routing domain (SR domain): the set of nodes participating in
>the source-based routing model.  These nodes may be connected to the
>same physical infrastructure (e.g., a Service Provider's network).
>They may as well be remotely connected to each other (e.g., an
>enterprise VPN or an overlay).
>
>
I read "same physical infrastructure (e.g., a Service Provider's network)."
as something like an ISP network, operated by a single "operator"/entiy, so
the SR traffic stays within what would commonly be called a "network".
I read "remotely connected to each other (e.g., an enterprise VPN or an
overlay)." as something where a packet (SR or whatever) is encapsulated as
the payload of a new packet -- e.g a packet from my laptop on my enterprise
VPN is encapsulated in the new packet by the VPN widget/software, and
decapsulated by the other end.



> This may go against your expectations (it may even go against reasonable
> expectations), but it is what it is.
>
> In the light of this, and with the understanding of how overlays are built
> and used (especially for VPNs), we explicitly looked in this document to
> provide a simple way that SR-capable sites may be interconnected using a
> concatenation of tunnels between SR-capable nodes in the wider network.


Yup -- and I'm happy with this as a concatenation of actual tunnels (IPIP,
GRE, IPSEC, etc) - my concern comes in if this is used for "raw" SR traffic
(where the destination is an endpoint, and not a specific decapsulation
device). The document says: "The various ASes that provide connectivity
between the ingress and egress sites could each be constructed differently
and use different  technologies such as IP, MPLS with global table routing
native BGP to  the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN." - if
this is actually a VPN style or real overlay, I'm fine, but this isn't
clear to me...


> As you'll see from the document, this doesn't involve any changes to SR,
> but does make use of SR's ability to use a SID to identify a node or a
> tunnel. Our only new stuff is to allow BGP to distribute information in a
> way that handles a site having multiple gateways and to cope with multiple
> possible paths between sites. If an ASBR (BGP peer) is unable to process
> the BGP extensions or is not SR-capable, it will not participate.
>
> > The document says: "The solution defined in this document can be seen in
> the
> > broader context of SR domain interconnection in
> > [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic
> > originating in one SR domain often terminates in another SR domain, but
> must
> > transit a backbone network that provides interconnection between those
> > domains." -- is it unclear to me if this is really what is being
> proposed...
>
> Again (as per the many discussions during IESG review), s/domain/site/
> That was a bad mistake by the authors (who really love the use of the word
> 'domain' as applied in all of the TEAS work).
> To be clear, all interconnected SR sites form part of the same
> 8402-SR-domain.
>
>
Hmmm... This *might* address my concern, but I will need to reread this
definition of domain. I have a horrible feeling that my concern/grump isn't
with this draft, but rather with RFC8402...



> We have fixed the use of site/domain in the working copy (which we hope to
> post later today).
>
> > I'm hoping that I'm really misunderstanding something here -- please
> educate me.
>
> Do you consider yourself educated now, or merely disciplined? 
>

Would you settle for "confused"?  :-P

W



>
> Cheers,
> Adrian
>
>

-- 
The computing scientist’s main challenge is 

[bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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 DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

I hope that I'm just misunderstanding something obvious, but I strongly support
John's DISCUSS -- when SR was "approved" it was with the understanding that it
would only be used within "real" limited domains, and would never be sent
outside of closed/limited network.

The document says: "The solution defined in this document can be seen in the
broader context of SR domain interconnection in
[I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic
originating in one SR domain often terminates in another SR domain, but must
transit a backbone network that provides interconnection between those
domains." -- is it unclear to me if this is really what is being proposed...

I'm hoping that I'm really misunderstanding something here -- please educate me.





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

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection

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-evpn-proxy-arp-nd/



--
COMMENT:
--

Thank you for engaging with, and addressing the OpsDir review, and thanks to
Joe for performing it...



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-na-flags-08: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-na-flags-08: No Objection

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-evpn-na-flags/



--
COMMENT:
--

[ Update: Thank you for addressing my DISCUSS concern. ]

Other than my DISUCSSes, I found this document to be well written and easy to
understand - thank you for writing it...



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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)

[Warren Kumari]

Hi there,

Just a quick note to say thank you for addressing my concerns; I
appreciate your adding text even though the concern isn't (strictly)
within this document.

I've just cleared my DISCUSS.

W



On Mon, Oct 12, 2020 at 5:10 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Warren,
>
>
>
> OK, thanks for explaining.
>
>
>
> Added the following text in rev 08. Let me know if it satisfies your concern. 
> I understand it is a general concern about proxy-arp/nd in EVPN networks and 
> not about this specific document.
>
>
>
>
>
> The same security considerations described in [RFC7432] apply to this
>
>document.  In general, it is worth noting that the use of Proxy ARP/
>
>ND in EVPN BDs may add some security risks.  Attackers can make use
>
>of ARP/ND messages to create state in all the PEs attached to the
>
>same BD as the attacker and exhaust resources in those PEs.
>
>Therefore, additional security mechanisms may be needed.  Some
>
>examples of such additional security mechanisms are e.g., limit the
>
>number of Proxy ARP/ND entries per-BD/per-port, or monitor closely
>
>the rate at which hosts create dynamic Proxy-ARP/ND entries.
>
>
>
>
>
> Thank you!
>
> Jorge
>
>
>
> From: Warren Kumari 
> Date: Sunday, October 11, 2020 at 3:39 PM
> To: Rabadan, Jorge (Nokia - US/Mountain View) 
> Cc: The IESG , draft-ietf-bess-evpn-na-fl...@ietf.org 
> , bess-cha...@ietf.org 
> , bess@ietf.org , Bocci, Matthew (Nokia 
> - GB) 
> Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: 
> (with DISCUSS and COMMENT)
>
>
>
>
>
> On Fri, Oct 9, 2020 at 7:38 AM Rabadan, Jorge (Nokia - US/Mountain View) 
>  wrote:
>
> Hi Warren,
>
>
>
> Thank you for reviewing!
>
>
>
> Please see some comments in-line and let us know if we still need to add 
> information to the security section.
>
>
>
> Thx
>
> Jorge
>
>
>
> From: Warren Kumari via Datatracker 
> Date: Wednesday, September 23, 2020 at 6:17 PM
> To: The IESG 
> Cc: draft-ietf-bess-evpn-na-fl...@ietf.org 
> , bess-cha...@ietf.org 
> , bess@ietf.org , Bocci, Matthew (Nokia 
> - GB) , Bocci, Matthew (Nokia - GB) 
> 
> Subject: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with 
> DISCUSS and COMMENT)
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-na-flags-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-evpn-na-flags/
>
>
>
> --
> DISCUSS:
> --
>
> Be ye not afraid! This DISCUSS should be fairly trivial to address...
>
>
>
> This allows for more information to be carried with MAC/IP Advertisements. It
> seems to me that this gives a DoS-style attacker more opportunities to exhaust
> state on routers - I could sit on a wire and create lots of ARP/ND states 
> (make
> up new IP and MAC combinations), causing this to be propagated and burning
> memory / state / etc.
>
> This is somewhat discussed in RFC 7432, but the technique in this document
> seems like it makes this issue somewhat worse - a single sentence in the
> Security Considerations noting it would satisfy me (as would an explanation
> that I'm mistaken :-)).
>
> 
>
> [jorge] we’re happy to add any other explanations in the security section, 
> however I thought your concern could have been addressed by this existing 
> sentence:
>
>“In addition, this document adds pieces of information that impact on
>
>the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND
>
>tables, and therefore the resolution protocols for IPv4 and IPv6
>
>addresses.”
>
>
>
> Also, can you please clarify what you mean by this?:
>
> “this gives a DoS-style attacker more opportunities to exhaust
> state on routers - I could sit on a wire and create lots of ARP/ND states 
> (make
> up new IP and MAC combinations), causing this to be propagated and burning
> memory / state / etc.”
>
> Note that the new flags come in an extended community, which is not part of 
> the route key, hence re

[bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-na-flags-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-evpn-na-flags/



--
DISCUSS:
--

Be ye not afraid! This DISCUSS should be fairly trivial to address...

This allows for more information to be carried with MAC/IP Advertisements. It
seems to me that this gives a DoS-style attacker more opportunities to exhaust
state on routers - I could sit on a wire and create lots of ARP/ND states (make
up new IP and MAC combinations), causing this to be propagated and burning
memory / state / etc.

This is somewhat discussed in RFC 7432, but the technique in this document
seems like it makes this issue somewhat worse - a single sentence in the
Security Considerations noting it would satisfy me (as would an explanation
that I'm mistaken :-)).

I also support EK & Rob's DISCUSSes


--
COMMENT:
--

Other than my DISUCSSes, I found this document to be well written and easy to
understand - thank you for writing it...



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: No Objection

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-rfc5549revision/



--
COMMENT:
--

I found this document really hard to review - not because the document itself
was unclear, but rather because I had to keep going back and forth between it
and RFC5549. Passing it though 'diff' helped some, but a few sentences
explaining the differences would have helped immensely; it would also help
RFC5549 implementers understand what they need to change to be compliant...



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

[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection

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-evpn-vpls-seamless-integ/



--
COMMENT:
--

I'm staying out of the "what track should it be" discussion...

Thanks to Linda Dunbar for the OpsDir review.


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

Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-etree-13: (with COMMENT)

[Warren Kumari]

Awesome, thank you.

W

On Sun, Oct 29, 2017 at 2:42 PM, Ali Sajassi (sajassi)
<saja...@cisco.com> wrote:
>
> Hi Warren,
>
> Please see my replies inline marked with ³Ali>"
>
> On 9/3/17, 3:56 PM, "Warren Kumari" <war...@kumari.net> wrote:
>
>>Warren Kumari has entered the following ballot position for
>>draft-ietf-bess-evpn-etree-13: No Objection
>>
>>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-evpn-etree/
>>
>>
>>
>>--
>>COMMENT:
>>--
>>
>>[ I wrote this review back on Aug 8th, but the balloting wasn't open then
>>- I
>>believe that there has been a new revision since, and so some of these may
>>already have been addressed. ]
>>
>>I'm balloting No Objection, but I do have significant reservations;
>>because of the number of nits the document is quite hard to read - a
>>number of
>>these required re-reading the sentence multiple times, guessing at what
>>the
>>sentence is trying to says, etc. Many of these are really obvious (e.g
>>see nit
>>#14 below) and it makes me concerned that the document hasn't been
>>sufficiently
>>reviewed.
>>
>>In addition, the RFC Editor would have caught these, but it doesn't seem
>>reasonable to rely on them to make documents readable, nor to waste
>>multiple
>>reviewers time addressing what could easily have been caught with a
>>simple read
>>though.
>>
>>Questions / Notes:
>>1: The document has 6 authors (one listed as an author) and a contributors
>>section -- is there a substantive difference between those above the fold
>>and
>>those below it?
>
> Ali> Merged ³Contributors² section into the ³Acknowledgements² section.
>>
>>2: This document uses a number of acronyms without expanding them on
>>first use.
>
> Ali> All acronyms should have been explained (or expanded) before their
> use. But, if there are any, please let me know.
>>
>>3: Section 8.1 Considerations for PMSI Tunnel Types
>>"The status of 0x7F may only be
>>   changed through Standards Action [RFC5226]." - what makes 0x7F
>>special? What
>>   is it reserved for?
>
> Ali> I updated that section in rev14.
>>
>>4: The shepherd writeup says:
>>Q: (16) Will publication of this document change the status of any
>>existing RFCs?
>>A: No change of the status of existing RFCs.
>>
>>I believe that this is incorrect, especially when compared with the Q/A
>>#17.
>
> Ali> This draft described enhancements/extension to procedures in RFC7432
> and RFC7623 when E-TREE service is needed.
>>
>>5: The IANA considerations section seems to be incorrect / transition
>>isn't
>>really described. The current registry says: 0xFB-0xFE Reserved for
>>Experimental Use
>>
>>This document changes that to be:
>>0x7B-0x7E  Reserved for Experimental Use
>
> Ali> The wording in the IANA section wasn¹t quite accurate. The draft
> doesn¹t change the already-defined values for experimental use but rather
> it expands it. I have updated the text to reflect that.
>>
>>While it "only" a change to an experimental range, by their very nature
>>you
>>don't know if anyone is using the current range. I think that the document
>>needs to be much more clear about the fact that it is changing this, and
>>also
>>what the implications are for people who are already using e.g: 0xFB -
>>from
>>what I can see, it could break existing deployments.
>
> Ali> The existing range for Experimental (0xFB-0xFE) doesn¹t change but
> rather it got expanded. It should be now clear in rev14.
>>
>>Nits:
>>
>>1: Section 2.1 Scenario 1: Leaf OR Root site(s) per PE
>>O: In such scenario, using tailored BGP Route Target (RT) import/export
>>   policies among the PEs belonging to the same EVI, can be used to
>>   restrict the communications among Leaf PEs.
>>P: In such scenario, tailored BGP Route Target (RT) import/export
>>   policies among the PEs belongi

Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)

[Warren Kumari]

On Sun, May 7, 2017, 7:35 PM Robert Raszuk <rob...@raszuk.net> wrote:

> Hi Warren,
>
> In the draft you have reviewed EVPN term is use interchangeably with term
> [RFC7432] which in turn is also already listed and defined in the Normative
> References section (2nd from the top).
>


Yes, and I  read RFC7432 when I first reviewed this document - but I only
knew that was the one to read after grepping though RFCs for "EVPN" -- is
there any reason for the authirs *not* to make things easier for your
readers by saying: "
This document describes how EVPN [RFC7432] can be ..."?


> Personally if you assume that the reader of this document is not familiar
> with EVPN I would also recommend to read few other L2 VPN related documents
> as prerequisite before jumping to this one:
>
> - RFC 7209 and all VPN related documents included in its references
>
> - RFC 7432 and all VPN related documents included in its references
>
> - all VPN related documents included in references of
> draft-ietf-bess-evpn-vpws
>

That sounds like a fine idea - perhaps the authors should add something
like "Readers of this document are expected to be familiar with RFC7209 and
RFC7432."
Mainly I don't understand why we wouldn't want to make it easier for
someone new to the technology...

W




> - only then the draft in question itself.
>
> Kind regards,
> Robert.
>
>
> On Sun, May 7, 2017 at 7:05 PM, Warren Kumari <war...@kumari.net> wrote:
>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-bess-evpn-vpws-13: No Objection
>>
>> 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-evpn-vpws/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> [ For -11 / -12 ]
>> This document is very heavy on the acronyms, and could do with some
>> expanding of these -- for example, the document starts out with "This
>> document describes how EVPN can be used...". I'm no MPLS VPN person, so
>> much time was spent searching to try figure out what everything meant.
>>
>> I also agree with Spencer's "In multihoming scenarios, both B and P flags
>> MUST NOT be both set. " being hard to parse, and disagree with Acee that
>> is it clear.
>>
>> [ For -13 ]
>> The draft was revised to address Alia's DISCUSS, and also Spencer's
>> "traditional way" and "both B and P flags MUST NOT be both set" comment,
>> but still does not expand EVPN; I also agree with Spencer that it would
>> be helpful to expand P2P on first use.  I reread the document and have
>> some additional comments - note that these are are only comments, but I
>> think that they would make the document more readable...
>>
>> 1: Introduction:
>> "that in EVPN terminology would mean a single pair of Ethernet Segments
>> ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing
>> failure and 'Ethernet Segments (ES)' was intended? If not,
>>
>> You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick
>> with one.
>>
>> 1.1: Terminology:
>> "EVI: EVPN Instance." --  Ok, but EVPN is still not defined /
>> referenced.
>>
>> 3.1  EVPN Layer 2 attributes extended community
>> " A PE that receives an update with both B and P flags set MUST treat
>> the
>>  route as a withdrawal. If the PE receives a route with both B and P
>>  clear, it MUST treat the route as a withdrawal from the sender PE."
>> Do the above 2 sentences say the same thing? It sure sounds like
>> repetition, if not, please explain the difference. If not, removing one
>> would make this less confusing.
>>
>> Figure 3: EVPN-VPWS Deployment Model
>> You use the terms / labels "PSN1", "PSN2" - what are these? "Provider
>>  Network"?
>>
>>
>> ___
>> 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] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-vpws-13: No Objection

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-evpn-vpws/



--
COMMENT:
--

[ For -11 / -12 ] 
This document is very heavy on the acronyms, and could do with some
expanding of these -- for example, the document starts out with "This
document describes how EVPN can be used...". I'm no MPLS VPN person, so
much time was spent searching to try figure out what everything meant.

I also agree with Spencer's "In multihoming scenarios, both B and P flags
MUST NOT be both set. " being hard to parse, and disagree with Acee that
is it clear.

[ For -13 ]
The draft was revised to address Alia's DISCUSS, and also Spencer's
"traditional way" and "both B and P flags MUST NOT be both set" comment,
but still does not expand EVPN; I also agree with Spencer that it would
be helpful to expand P2P on first use.  I reread the document and have
some additional comments - note that these are are only comments, but I
think that they would make the document more readable...

1: Introduction:
"that in EVPN terminology would mean a single pair of Ethernet Segments
ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing
failure and 'Ethernet Segments (ES)' was intended? If not, 

You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick
with one.

1.1: Terminology:
"EVI: EVPN Instance." --  Ok, but EVPN is still not defined /
referenced.

3.1  EVPN Layer 2 attributes extended community
" A PE that receives an update with both B and P flags set MUST treat
the
 route as a withdrawal. If the PE receives a route with both B and P
 clear, it MUST treat the route as a withdrawal from the sender PE."
Do the above 2 sentences say the same thing? It sure sounds like
repetition, if not, please explain the difference. If not, removing one
would make this less confusing.

Figure 3: EVPN-VPWS Deployment Model
You use the terms / labels "PSN1", "PSN2" - what are these? "Provider
 Network"?


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

Re: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Warren Kumari]

[ + authors ]

On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk  wrote:
> Hi Warren,
>
>> This is clearly not unanimous/ not everyone is happy, but (in my view)
>> there is *rough* consensus for this to progress.
>
>
> The group of users of BGP which this update impacts the most are members
> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
> to all AFI/SAFIs.

I'll happily admit that I have not been following BESS at all, and so
know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
if BESS is affected to the level that they should have been explicitly
invited to comment?

> IMO before you progress anywhere with this IETF LC BESS WG should express
> their formal opinion on it.
>
> Example of in or out eBGP policy where you are sending MAC addresses in
> EVPN AF needs to be provided and explained why it makes sense. Likewise
> examples of RTC AF for L3VPN Inter-as needs to be discussed.
>
> Otherwise the group of people which defined a lot of non ISP uses of BGP may
> be
> suddenly surprised down the read for keeping them out of the loop and have
> customers loosing reachability upon compliant non sequential router OS
> upgrade.

The authors are busy incorporating some final edits (including some
suggested by Alvaro). I would have hoped that all affected parties
would have seen the discussions on GROW / IDR / the IETF LC.

I ask people to please withhold judgment until the new version is released.


I'm about to board a plane (to Budapest), and will be out of email for
many hours...
W

 >
> Cheers,
> Robert.

>
> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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