Re: [bess] [Last-Call] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Robert Raszuk]

Hi John,

I think I am getting to what you are saying ... or maybe not.

If I am reading it correctly you say that running BGP over TLS or DTLS is
not standardized hence we should be very careful in putting this in the new
documents.

Would you be of a different opinion if authors say instead that the
intention is to run BGP over TCP over TLS or DTLS ?

If so for clarity I would think this could be a helpful editorial change.

If however you are saying that when defining a new transport be it some
form of tunnel (EVPN, SR, MPLS over IP, MPLS over MPLS etc ...) we need to
recycle all protocols which run over TCP or UDP to sort of bless them for
running on such new transport then I think this is not achievable in our
short life time.

Best,
R.




On Tue, Feb 6, 2024 at 9:30 PM John Scudder  wrote:

> > On Feb 6, 2024, at 2:48 PM, Robert Raszuk  wrote:
> >
> > I have been using BGP over TCP over TLS and BGP over TCP over DTLS for
> years testing Sproute's SDWAN solution. Works perfectly fine. In fact it
> performs much better then BGP over TCP over IPSec.
>
> Cool. There are a great many things in the world that work and are nice
> but haven’t been standardized. We tend to avoid basing standards on them.
> Sometimes we do say “oh hey I’d like to base a standard on foo” and so we
> make an RFC for foo so that we have something to cite. But AFAICT that is
> not currently the case with the present example.
>
> —John
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Robert Raszuk]

Hi John,

Trimming a bit the list of to/cc

I noticed you stated this:

".. as far as I’m aware, there is no IETF specification for BGP over TLS,
and I don’t expect that there will ever be a specification for BGP over
DTLS, given that BGP assumes a stream transport..."

So that got me a bit curious as I have been using BGP over TCP over TLS and
BGP over TCP over DTLS for years testing Sproute's SDWAN solution. Works
perfectly fine. In fact it performs much better then BGP over TCP over
IPSec.

And now you said something even more interesting:

".. It’s possible to layer lots of things over lots of other things..."

That sounds like using TCP over TLS or DTLS is a bad thing ... which
clearly is not.

Cheers,
Robert

PS. In the subject spec I found many references to running TLS or DTLS to
RRs or PEs and having BGP established there. I would rather not delete DTLS
from it.







On Tue, Feb 6, 2024 at 8:39 PM John Scudder  wrote:

> Hi Robert,
>
> > On Feb 6, 2024, at 1:49 PM, Robert Raszuk  wrote:
> >
> > Hi John,
> >
> > https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/
>
> See my earlier reply to Linda.
>
> > And for DTLS ... isn't this simply TCP over DTLS which works just fine ?
>
> I’m not sure what you’re getting at here. It’s possible to layer lots of
> things over lots of other things. That doesn’t mean that it makes sense to
> do so, or that it’s something you can just mention in (literally) a single
> word in a spec and imagine you’ve provided enough detail. In this case,
> Linda said she planned to remove the mention of DTLS, which makes more
> sense to me, so I guess we don’t need to keep discussing it.
>
> —John
>
> >
> > Many thx,
> > R.
> >
> >
> >
> > On Tue, Feb 6, 2024 at 4:38 PM John Scudder  40juniper@dmarc.ietf.org> wrote:
> > I haven’t done a full review of this document, but I did notice that
> Roman Danyliw balloted DISCUSS on version 15 [1], asking, among other
> things, "Are there pointers for BGP over DTLS? Over TLS?”. This doesn’t
> appear to have been addressed, either in Linda’s reply to Roman [2], or in
> the text of the document. It seems ill-advised to be last calling a
> document with an unaddressed DISCUSS. For what it’s worth, Roman’s point
> seems to me to be on target — as far as I’m aware, there is no IETF
> specification for BGP over TLS, and I don’t expect that there will ever be
> a specification for BGP over DTLS, given that BGP assumes a stream
> transport.
> >
> > $0.02,
> >
> > —John
> >
> > [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ballot/#draft-ietf-bess-bgp-sdwan-usage_roman-danyliw
> > [2]
> https://mailarchive.ietf.org/arch/msg/bess/-AT3GpMR6rr6-ywB5vWD7EbGk0w/
> >
> > > On Feb 1, 2024, at 11:58 AM, The IESG  wrote:
> > >
> > >
> > > The IESG has received a request from the BGP Enabled ServiceS WG
> (bess) to
> > > consider the following document: - 'BGP Usage for SD-WAN Overlay
> Networks'
> > >   as Informational RFC
> > >
> > > 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
> > > last-c...@ietf.org mailing lists by 2024-02-15. 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
> > >
> > >
> > >   The document discusses the usage and applicability of BGP as the
> > >   control plane for multiple SD-WAN scenarios. The document aims to
> > >   demonstrate how the BGP-based control plane is used for large-
> > >   scale SD-WAN overlay networks with little manual intervention.
> > >
> > >   SD-WAN edge nodes are commonly interconnected by multiple types of
> > >   underlay networks owned and managed by different network
> > >   providers.
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN7dGgEtnA$
> > >
> > >
> > >
> > > No IPR declarations have been submitted directly on this I-D.
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > IETF-Announce mailing list
> > > ietf-annou...@ietf.org
> > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN5i_8mwVg$
> >
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Robert Raszuk]

Hi John,

https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/

And for DTLS ... isn't this simply TCP over DTLS which works just fine ?

Many thx,
R.



On Tue, Feb 6, 2024 at 4:38 PM John Scudder  wrote:

> I haven’t done a full review of this document, but I did notice that Roman
> Danyliw balloted DISCUSS on version 15 [1], asking, among other things,
> "Are there pointers for BGP over DTLS? Over TLS?”. This doesn’t appear to
> have been addressed, either in Linda’s reply to Roman [2], or in the text
> of the document. It seems ill-advised to be last calling a document with an
> unaddressed DISCUSS. For what it’s worth, Roman’s point seems to me to be
> on target — as far as I’m aware, there is no IETF specification for BGP
> over TLS, and I don’t expect that there will ever be a specification for
> BGP over DTLS, given that BGP assumes a stream transport.
>
> $0.02,
>
> —John
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ballot/#draft-ietf-bess-bgp-sdwan-usage_roman-danyliw
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/-AT3GpMR6rr6-ywB5vWD7EbGk0w/
>
> > On Feb 1, 2024, at 11:58 AM, The IESG  wrote:
> >
> >
> > The IESG has received a request from the BGP Enabled ServiceS WG (bess)
> to
> > consider the following document: - 'BGP Usage for SD-WAN Overlay
> Networks'
> >   as Informational RFC
> >
> > 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
> > last-c...@ietf.org mailing lists by 2024-02-15. 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
> >
> >
> >   The document discusses the usage and applicability of BGP as the
> >   control plane for multiple SD-WAN scenarios. The document aims to
> >   demonstrate how the BGP-based control plane is used for large-
> >   scale SD-WAN overlay networks with little manual intervention.
> >
> >   SD-WAN edge nodes are commonly interconnected by multiple types of
> >   underlay networks owned and managed by different network
> >   providers.
> >
> >
> >
> >
> > The file can be obtained via
> >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN7dGgEtnA$
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > ___
> > IETF-Announce mailing list
> > ietf-annou...@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN5i_8mwVg$
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Robert Raszuk]

All,

Looking at all the drafts mentioned I do think there are actually two
different scenarios being considered and perhaps it is actually beneficial
to treat them separately.

Original draft allowed to signal link bw in situations where you peer from
different boxes. Path hiding is not an issue. Most likely such signalling
is to be done in respect to underlay.

However newer proposals aim to enhance the overlay behaviour where via one
or the other technique path hiding issue of BGP is addressed.

Inter-AS option C is also an overlay so I would recommend to think twice
before influencing base idea with this deployment scenario.

To conclude let's also realize that link bw is actually not a property of a
path as it is a property of the next hop binded to such path (how easy or
difficult it is to get to such next hop). And here I must say that the
draft Kaliraj & Minto proposed draft-kaliraj-idr-multinexthop-attribute
could possibly be used as a vehicle for its encoding.

The clear benefit for such perspective is ability to signal helper next
hops addresses with their link bw metrics possible hashing spread without
need to explode BGP with lot's of paths respectively if that is done by
add-paths or RD prepend.

Thx,
Robert


On Mon, Jun 26, 2023 at 11:44 PM Alvaro Retana 
wrote:

> On June 26, 2023 at 5:27:39 PM, Jeff Tantsura wrote:
>
> Jeff:
>
> > Over the last couple of years I have reached out to the authors of the
> > original draft at least twice with a request to refresh the draft and
> bring
> > the necessary changes in, without much success though.
> >
> ...
> > Note that there’s also an EVPN specific draft (standard track).
>
> That made me go look -- I found two related documents!  Are these what
> you're referring to?
>
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb
>
>
> > I’d be happy to volunteer to help managing the mess ;-)
>
> I know the idr/bess-chairs are listening. ;-)
>
>
> Alvaro.
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Robert Raszuk]

Hi,

> I agree that the use case presented should be addressed, but I don't
think the document is ready for WGLC,

Indeed.

In fact it is clear by now that
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
needs to be rewritten to accommodate both 4 octet ASNs (instead of
proposing use of AS_TRANS) as well as define support for transitive
community use.

On the last one inspection of the IANA registry reveleas subtype 0x04 as
"Juniper Transitive Link Bandwidth" and the date 25th April 2023.

[image: image.png]

Interesting especially that I do not recall any discussions in IDR about
this this year ...

Cheers,
R.


On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana 
wrote:

> Hi!
>
> I took a look at this document.
>
> I agree that the use case presented should be addressed, but I don't think
> the document is ready for WGLC, or even necessary (see below).  In fact,
> I'm having a hard time understanding how it can progress if it depends on
> an expired draft, the proposed changes are not specific, etc.
>
>
> The meat of the document (beyond the explanation of the use case) is (from
> §1):
>
>The new use-case mandates that the router calculates the aggregated
>link-bandwidth, regenerate the DMZ link bandwidth extended community,
>and advertise it to EBGP peers.
>
>
> I-D.ietf-idr-link-bandwidth expired in 2018.  I have seen no indication
> from the authors that it will be refreshed.  I know that implementations
> exist, but that is orthogonal to the need to reference this document as
> Normative.
>
>
> The rest of the document is mostly dedicated to describing the use case,
> but the description of the actions is loose (at best); for example, there
> is no specification about how "the router calculates the aggregated
> link-bandwidth".  Yes, we can all guess/assume what it means, but that
> needs to be documented.
>
> Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from
> this document could be covered there.  In fact, there is already a hint to
> the ability to regenerate the community based on received information (from
> §3):
>
>Alternatively CEs of the site, when advertising IP routes to PE1
>and PE2, could add the link bandwith community to these
>advertisements, in which case PE1 and PE2, when originating VPN-IP
>routes, would use the bandwidth value from the IP routes they
>received from the CEs to construct the link bandwidth community
>carried by these VPN-IP routes.
>
>
> In summary, given that this document depends on
> I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be
> "merged" into it.
>
>
> Alvaro.
>
> On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) (
> matthew.bo...@nokia.com) wrote:
>
> Hi IDR WG
>
>
>
> The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02
> (draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and
> load-balancing
> ), for which
> we are considering starting a working group last call.
>
>
>
> Please could you review the draft and post any comment to the BESS mailing
> list (bess@ietf.org) by 25th June 2023.
>
>
>
> Thanks
>
>
>
> Matthew and Stephane
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Suggestion on v4-only/v6-only drafts

[Robert Raszuk]

Hi Ketan,

> I believe you are referring to the "BCP" (of Informational) content of
these drafts.

Quite the opposite ... I am referring to the Standards Track content ..
especially in respect to the IDR draft:

https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/

I do not find anything new in it that would not have already been
standardized. Especially I see lot's of text verbatim copied from RFC8950.

As far as BESS drafts I refrain from commenting as those drafts are IMO
unreadable. If you have an abstract spanning 3 pages and a quote to list
over 30 references that is right there not a good sign.

Thx,
R.


On Fri, Nov 11, 2022 at 1:43 PM Ketan Talaulikar 
wrote:

> Hi Robert,
>
> I believe you are referring to the "BCP" (of Informational) content of
> these drafts. If so, my impression is that the authors wanted to put this
> information together for the benefit of the operator community. I'll let
> them respond.
>
> You can see my comments during the BESS WG adoption poll for one of the
> drafts here [1].
>
> My concern was more the parts that need standardization need to be called
> out very succinctly (in hopefully a short draft) and the rest is all simply
> informational material that can be clubbed together to perhaps make more
> efficient use of reviewers time.
>
> Thanks,
> Ketan
>
> [1]
> https://mailarchive.ietf.org/arch/msg/bess/Wj-Y_m-t7C0bZ90NM-hmQbOYoPY/
>
>
> On Fri, Nov 11, 2022 at 5:59 PM Robert Raszuk  wrote:
>
>> Hi Ketan,
>>
>> If you are referring to interconnecting v4 only sites draft I have number
>> of comments:
>>
>> * The draft is not needed at all
>>
>> * we can seamlessly interconnect v4 sites over v6 core using v4 mapped v6
>> addresses
>>
>> * Zero control plane change is required/needed
>>
>> * number of vendors are shipping it
>>
>> Moreover sites even if today speaking v4 only sooner then later will talk
>> also v6. We can not ship a std track document which makes v6 deployment
>> harder or no-op for any site.
>>
>> Best,
>> Robert
>>
>> On Fri, Nov 11, 2022, 11:19 Ketan Talaulikar 
>> wrote:
>>
>>> Hi Gyan,
>>>
>>> Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 in
>>> IDR) as we lost time due to the audio issues:
>>>
>>> (1) put the portions to be standardized (very focussed/small hopefully)
>>> in one single draft and post/share with both IDR and BESS since you are
>>> changing NH encoding (from what I heard?)
>>> (2) all other informational/BCP material could be combined in a single
>>> draft (perhaps the existing BESS WG draft)
>>>
>>> IMHO, that would facilitate an appropriate focussed review of the
>>> content/proposals.
>>>
>>> Thanks,
>>> Ketan
>>>
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Suggestion on v4-only/v6-only drafts

[Robert Raszuk]

Hi Ketan,

If you are referring to interconnecting v4 only sites draft I have number
of comments:

* The draft is not needed at all

* we can seamlessly interconnect v4 sites over v6 core using v4 mapped v6
addresses

* Zero control plane change is required/needed

* number of vendors are shipping it

Moreover sites even if today speaking v4 only sooner then later will talk
also v6. We can not ship a std track document which makes v6 deployment
harder or no-op for any site.

Best,
Robert

On Fri, Nov 11, 2022, 11:19 Ketan Talaulikar  wrote:

> Hi Gyan,
>
> Sharing a couple of suggestions here for your 5 drafts (4 in BESS + 1 in
> IDR) as we lost time due to the audio issues:
>
> (1) put the portions to be standardized (very focussed/small hopefully) in
> one single draft and post/share with both IDR and BESS since you are
> changing NH encoding (from what I heard?)
> (2) all other informational/BCP material could be combined in a single
> draft (perhaps the existing BESS WG draft)
>
> IMHO, that would facilitate an appropriate focussed review of the
> content/proposals.
>
> Thanks,
> Ketan
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review

[Robert Raszuk]

Hey Igor,


> [IM] Agree. I understood it well before I started drafting. My goal was as
> less as possible touch to VPN and other mechanics. BGP NH tracking allows
> us to implement changes (update boxes) only for MH PEs.
>

Some deployments have up to 5000 CEs hanging off the PEs. And those
networks have 1000s PEs. We just can not propose a solution which would
melt one's underlay.

Sure you may just state oh well "use with caution" - my take we can do
better.



> they do from day one. You can easily remove all routes in a given VRF by
>> withdrawing the RD/64 prefix. Single BGP message.
>>
> [IM] Well, actually I totally missed this mechanic. It sounds really good
> and I'm surprised that it isn't widely used (at least I haven't encountered
> it). A careful reading of 4365/4659 didn't show me anything about it, from
> my understating, RD`s task is just to distinguish routes and nothing more.
> Maybe it is described anywhere else?
>

Well it came as part of discussions we have had 18 years ago about
aggregate withdraws:
https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt

I actually have built some images to test it in IOS :) But if you want to
refocus your draft and use RD based aggregation for withdrawals I am all
game to help. Within the last few months I have been approached with at
least three cases for such functionality :)

It does however touch on base BGP behaviour ... which is the ability to
withdraw more specific routes by less specific prefix. So it has to be
properly scoped to make it safe. Say only for SAFI 128.



> So in your case (Internet in a VRF) there is simple solution:
>>
>> Option I ) Put each CE into a separate VRF - when CE goes down - just
>> withdraw the /64 RD.
>>
> [IM] This is obviously not the way, especially for brownfields.
>

Not sure about that.



> Option II)  Alternatively you may ask your favourite vendor to allow
>> multiple RDs in a VRF - one per each CE. Withdraw mechanism will be the
>> same /64 per CE however no impact to the underlay .. still single next hop,
>> single forwarding label etc ... In this option in the case both CEs
>> advertise the same nets you would still advertise the single best path only
>> out of this VRF. Keep in mind however that paths will be different from
>> each CE so upon a CE failure while you can quickly remove the previously
>> advertised routes you need to announce  all of them again anyway with
>> different CE paths. So the solutions is not much better then smart
>> implementations and Option I.
>>
> [IM] This is more interesting. And I believe the described problem with a
> couple of CEs can be addressed by Add-Paths for VPNs.
>

See Add-paths for VPNs was never needed as good multihoming is done across
different PEs (where RDs would be unique).

On the other hand advertising multiple paths from a given VRF is not that
wise as repair is local and we have no interest to spray all the paths
everywhere ...note that what we care about is not control plane, but
connectivity for customer packets (connectivity restoration).

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

Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review

[Robert Raszuk]

Hi Igor,

Thank you for sharing your draft. I am cc-ing IDR as you are proposing
modifications to core BGP.

What you are proposing IMO will work fine and in fact I recall we had
number of discussions on this in the past some of which resulted in
definition of Edge_Discriminator Attribute as described
in draft-pmohapat-idr-fast-conn-restore-03

However what you are proposing has serious scaling limits and impact to
underlay if anyone would like to do this for lot's of VRFs.

Let me observe that below quote is not correct:

   Neither IP VPN [RFC4364] nor IPv6 VPN [RFC4659] have a mass routes
   withdrawal mechanism.

they do from day one. You can easily remove all routes in a given VRF by
withdrawing the RD/64 prefix. Single BGP message.

So in your case (Internet in a VRF) there is simple solution:

Option I ) Put each CE into a separate VRF - when CE goes down - just
withdraw the /64 RD.

Option II)  Alternatively you may ask your favourite vendor to allow
multiple RDs in a VRF - one per each CE. Withdraw mechanism will be the
same /64 per CE however no impact to the underlay .. still single next hop,
single forwarding label etc ... In this option in the case both CEs
advertise the same nets you would still advertise the single best path only
out of this VRF. Keep in mind however that paths will be different from
each CE so upon a CE failure while you can quickly remove the previously
advertised routes you need to announce  all of them again anyway with
different CE paths. So the solutions is not much better then smart
implementations and Option I.

Lastly, why is your draft on the Standards Track ? It does not define any
protocol extension so at best can be Informational.

Many thx,
Robert.


On Tue, Aug 23, 2022 at 3:45 PM Igor Malyushkin 
wrote:

> Hi all,
>
> Recently I posted a draft about a problem I've encountered as an ISP
> engineer. It is related to IP VPN convergence and especially is applicable
> to multihomed CEs. I think the solution can be useful for many types of IP
> VPN deployments, but one of the main drivers for me was the Internet in the
> VRF case. Lots of networks I know including the network I operate
> distribute Internet prefixes by means of IP VPN instead of the GRT. The
> document addresses one of the problems related to this approach but is not
> confined to it.
>
> I kindly ask the WG for comments and suggestions. Also, as I'm absolutely
> new to the IETF process I hope that I wasn't wrong with the WG, as I think
> that IP VPN problems are related to BESS.
>
>
> https://datatracker.ietf.org/doc/draft-malyushkin-bess-ip-vpn-abstract-next-hops/
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

[Robert Raszuk]

Hi Dhananjaya,

> DR## Can you check the Steering requirements section 6.2 ?

> It does include fallback to different colors / best effort. Please do
comment .


I see .. The subject of that section does not reflect the "fallback"
action.


But it addresses only part of the point I was making.


The other part was how do you communicate to the user application that
service is now degraded ?


How can an app increase its buffers when fallback from gold to silver is
triggered ?


In general what is described in section 6.2 is all very static. I am not
seeing a way to express colors (indicate intent) when I use SRv6
encapsulation directly from compute edge - as some operators are already
doing - and even section 3.2 in the original draft just talks about CEs and
VPNs. But as more and more services are starting to be originated directly
by compute nodes CE may just play a P node role.


Many thx,

R.




On Sun, Jul 17, 2022 at 12:10 PM Dhananjaya Rao (dhrao) 
wrote:

> Hi Robert,
>
>
>
> Thank you for the rapid review and insightful comments, as usual.
>
>
>
> Please see inline (DR##)
>
>
>
> *From: *Robert Raszuk 
> *Date: *Saturday, July 16, 2022 at 4:18 PM
> *To: *"Dhananjaya Rao (dhrao)" 
> *Cc: *"i...@ietf.org" 
> *Subject: *Re: [Idr] New draft
> "draft-hr-spring-intentaware-routing-using-color"
>
>
>
> Hello Dhananjaya,
>
>
>
> I have a few higher level questions/comments in respect to the shared
> document.
>
>
>
> #1 - Any well design service will very often try use multiple
> *independent* (ie. not closely cooperating administration) transits. It
> surprises me that none of the documents are trying to normalize at least a
> few colors such that intent aware transit across independent parties can be
> comparable by end customers.
>
>
>
> DR## Apt point. In fact, a similar comment has been made by a couple of
> other collaborators as well. Certain well-known common services could in
> fact be assigned well-known colors for use across providers (or independent
> transits as you stated). The analogy was to the current well-known BGP
> Communities.
>
>
>
> The current version does not venture into this aspect. It can certainly be
> included in the document. We would welcome further inputs on it.
>
>
>
>
>
> #2 - I love requirements as listed in 6.3.3 ! Note that many
> networks today are light years from meeting those requirements. So what
> this section is essentially saying is - if you do not meet those basic
> requirements forget about interaware transit. This is good.
>
>
>
> DR## Ack. All requirements may not apply to all intents, and there likely
> will be considerations of trade-offs when enabling them in networks.
>
>
>
> #3 - I am disappointed that the presented document does not say a word
> about intent/color to other color(s) or to best effort fallbacks. IMO I
> think it is extremely important and in fact should be part of dynamic
> signalling.
>
>
>
> DR## Can you check the Steering requirements section 6.2 ?
>
> It does include fallback to different colors / best effort. Please do
> comment .
>
>
>
> #4 - How colors are reflected in routing ? In other words if I want to
> transit over paths which do not use satellite links and suddenly there is
> failure of all critical terrestrial paths how do I get as the end customer
> signalled that ? Is my unicast route getting withdrawn ? In fact the
> document does not say what are the requirements for the customer CE. All
> pictures start from PE :).  Do I as a client need to participate in color
> aware routing at all ? Or is the mapping to a colorful path happening on
> the provider's edge based on something in the packet ?
>
>
>
> DR## FWIW,
> https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/
> did have a section (3.2) on VPN Service intent requirements, which covered
> extending intent-aware routing to the CE (and possibly beyond). These may
> not capture all possibilities – if you have suggestions, we will consider
> them.
>
>
>
> Since this current document is a merged effort, it has taken considerable
> time to agree on the content and text that should be included. Hence those
> requirements are not captured in the current version. But they should be
> included in upcoming versions, once reviewed.
>
>
>
> #5 - The entire architecture here seems to be locked to transit or
> connectivity service provided by a single set of closely cooperating
> administration. But as we all know more and more connectivity is moving (or
> has already moved) to SD-WAN or NaaS using native best effort transits
> provided by a number of ISPs in the underlay. It is ei

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Robert Raszuk]

Hi,

It also needs to be observed that
draft-ietf-bess-bgp-multicast-controller has a broader scope and also
covers mLDP functionality what may be extremely useful for networks which
are not green field and would like to transition from current to new
multicast trees.

Having solution in IDR which covers multicast tree setup partially and at
the same time a more complete one which has been already adopted and is
progressing as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which
are used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS
with draft-ietf-bess-bgp-multicast-controller since that WG is center of
gravity for all VPN/multi-tenant multicast related work.

Kind regards,
Robert


On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde  wrote:

> WG,
>
>
>
> I agree with Jeffrey that the BESS adopted draft
> draft-ietf-bess-bgp-multicast-controller provides
>
> Solution in the same problem space. It is good to discuss the two drafts
> before adopting
>
> draft-hb-idr-sr-p2mp-policy in IDR.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of * Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 8:17 PM
> *To:* Susan Hares ; i...@ietf.org
> *Cc:* 'p...@ietf.org' ; 'BESS' 
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> [+ BESS, PIM]
>
>
>
> Hi,
>
>
>
> I realized that in a hurry I did not respond to the specific questions
> below. Please see zzh> next to the questions.
>
>
>
> Looks like that there are some comments on BESS/PIM list and I will go
> through those to see if I have any addition/follow-up on those.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 6:30 AM
> *To:* Susan Hares ; i...@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> I am sorry for responding late. I somehow missed this.
>
>
>
> I think we should discuss the relationship with
> daft-ietf-bess-bgp-multicast-controller further before adopting this.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 10:28 AM
> *To:* i...@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> IDR WG:
>
>
>
> If you just wish to respond to the IDR list,
>
> you may respond to this email on the adoption call.
>
>
>
> Cheers, Sue
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org ] *On
> Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* i...@ietf.org; p...@ietf.org; bess@ietf.org
> *Subject:* [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
>
>
>
> This begins a 2 week WG adoption call for:
>
> draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)
>
>
>
> You can obtain the draft at:
>
> https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/
> 
>
>
>
> In your comments for this call please consider:
>
>
>
> Zzh> I want to point out that
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
> 
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> 
> why it was in the bess WG.
>
> Zzh> In addition, the bess draft supports **other** multicast trees (IP,
> mLDP besides SR-P2MP) using a consistent way.
>
>
>
> 1)  Does this technology support the SR P2MP features
>
> that distributes candidate paths which connect
>
> a multicast distribution tree (tree to leaves).
>
>
>
> Zzh> It is one way to use BGP to support that. The bess draft specifies
> another way.
>
>
>
> 2) Is the technology correctly specified for the
>
> NLRI (AFI/SAFI) and the tunnel encapsulation attribute
>
> additions (sections 2 and 3)?
>
>
>
> Zzh> The specified SAFI and tunnel encapsulation attribute additions are
> one way for the BGP signaling for SR-P2MP. The bess draft specifies another
> way.
>
>
>
> 3) Does the P2MP policy operation (section 4)
>
> provide enough information for those implementing this
>
> technology and those deploying the technology?
>
>
>
> 4) Do you think this multicast 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk]

Dear Yao,

The issue is not related to support or no support of a new feature
although that is also not well addressed in current BGP-4 specification.
The question is about coexistence of multiple transports and
service encoding for the same application.

I have a separate proposal on this, but did not post it before the cut off
date. So expect more on this after IETF in Vienna.

Best,
R.










On Tue, Mar 8, 2022 at 5:00 AM  wrote:

> Hi Robert,
>
> Thanks for sharing your detailed consideration on BGP capability and new
> NLRI.
> A few comments about the BGP capability solution. Please see inline [YAO].
>
>
> ==
>
> In BGP protocol any new service deployment using existing AFI/SAFI is not
> easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
> NLRI attributes. Main reason being is that using capabilities only goes one
> hop. In full mesh it all works perfect, but the moment you put RR in
> between BGP speakers things are getting ugly as capabilities are not
> traversing BGP nodes. /* Even in full mesh mixing transports for the same
> service is a serious challenge for routers when say multihomes sites are
> advertised from different PEs with different transport options */.
>
> [YAO] As you mentioned, in the scenario multihomes sites are advertised
> from different PEs with different transport options without RR, e.g, CE1
> are connected to PE1 and PE2, PE1 supports MPLS VPN while PE2 support SRv6
> VPN, PE3 is the peer of PE1 and PE2, imagine PE3 supports both
> capabilities,  I don't think this brings much difference between the
> configuration approach and BGP capability approach.
> If BGP capability is introduced, PE3 will receive both MPLS VPN and BGP
> VPN routes, how to process them is based on user's requirement,e.g,
> choosing one fixed type of routes, using the lastest routes, ECMP and so on.
> If configuration approach is used, how to configure is based user's
> requirement as well. Before configuration on PE1 and PE2, one should first
> decide whether PE3 wants to receive only one type of route or to receive
> both routes. And if PE3 receive both routes, the processing rule also
> should be considered.
> In a word, in scenario like this, the consideration on user's requirement
> is similar in both approach.
>
> Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
> sends a new format of the UPDATE messages. Well as today we also do not
> have a notion of conditional capabilities (only send when received from
> all) so if some of the RR peers do not support it you end up in partial
> service. One can argue that in this case the only deterministic model is to
> push the configuration from the management station and control partial
> deployment of the new service from mgmt layer.
>
> [YAO] By saying "RR peers", do you mean that in the scenario that there're
> multiple RRs, and they're peers of each other, if some of the RRs don't
> support the new BGP capability, the SRv6 service routes will not be sent to
> them thus result in losing part of the routes?
> If this is the case, I don't think it's a serious problem. No matter what
> new BGP capability one wants to introduce in this scenario, RRs are always
> required to support it if we want to get it right.
> If "RR peers" means other PEs, it is the expected result that PEs don't
> support the new capability will not receive the new kind of UPDATE
> messages.  So the dropping the  new routes sent to these PEs is not a
> problem.
> On the other hand, the management approach is always a practical option by
> not sending new messages to these PEs .
>
>
> Regards,
> Yao
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi John,

You have highlighted below a very important point. It was discussed among
co-authors, but perhaps not sufficiently during the BESS process as the
issue is really not a BESS WG problem.

In BGP protocol any new service deployment using existing AFI/SAFI is not
easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
NLRI attributes. Main reason being is that using capabilities only goes one
hop. In full mesh it all works perfect, but the moment you put RR in
between BGP speakers things are getting ugly as capabilities are not
traversing BGP nodes. /* Even in full mesh mixing transports for the same
service is a serious challenge for routers when say multihomes sites are
advertised from different PEs with different transport options */.

Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
sends a new format of the UPDATE messages. Well as today we also do not
have a notion of conditional capabilities (only send when received from
all) so if some of the RR peers do not support it you end up in partial
service. One can argue that in this case the only deterministic model is to
push the configuration from the management station and control partial
deployment of the new service from mgmt layer.

The natural alternative would be to never modify NLRI format once shipped
by RFC. When needed issue a new SAFI. Yes that is an option (and has always
been) but it also comes with its own set of issues. New SAFI is really
great to define for new service/feature etc ... Here however in the context
of this discussion we are changing transport for existing service.  And
just like it was the case with MPLS over UDP or  tunnel attribute etc ...
using a new SAFI would be very hard to deploy as there would need to be
well defined behaviour of BGP speakers receiving duplicate information for
the same VPN prefixes or receiving at one time only from single SAFI then a
bit later from the other one .. Of course one solution is to permit only
one SAFI for a given service at any given time, but that seems way too
restrictive too.

So to summarize while I am personally a huge proponent of new SAFI and new
capabilities to be defines for new service here I do have  some
reservations. It seems to me that deployment of new transport for VPN
service should be either network management driven or enabled when all
participating PEs support it. Enabling it automagically with one hop
capabilities seems to me like not a good thing as the data being sent in
the UPDATES is not optional and dropping it means dropping actual routes.

So at the current time the subject draft took a management approach.

Many thx,
Robert.

On Thu, Feb 24, 2022 at 2:04 AM John Scudder  wrote:

> Further to this point:
>
> > On Feb 18, 2022, at 3:32 PM, John Scudder  wrote:
> >
> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar 
> wrote:
> >>
> >>> 2. One area of concern I would have hoped IDR might have looked into
> is, the
> >>> document makes a creative use of the MPLS Label field of the NLRI to
> carry the
> >>> Function part of the SID. This means the SID is effectively split
> across the
> >>> NLRI and the Prefix-SID attribute. What are the potential error modes
> if the
> >>> Prefix-SID attribute should be lost from the route, while the NLRI is
> retained?
> >>>
> >>> (An obvious way of addressing this particular concern would be to
> define a new
> >>> NLRI type with the desired semantics, instead of creatively
> repurposing fields
> >>> within an existing NLRI type contrary to their definitions. Such an
> NLRI type
> >>> would, for example, presumably state in its specification that if it
> was
> >>> received without an accompanying Prefix-SID attribute, that would
> constitute an
> >>> error.)
> >>>
> >> KT> This document follows the approach similar as taken for extending
> MPLS EVPN RFC7432 by RFC8365.
> >
> > I take it you’re referring to RFC 8365 §5.1.3 which talks about using
> the MPLS Label field (or MPLS1 Label field) to carry the VNI in the
> presence of a BGP Encapsulation Extended Community? Yes, that seems like a
> pretty close analogue. And given this particular trick is only with
> VPN-type address families one can also argue that there’s not a risk of
> affected routes leaking into the big-I Internet, which is the typical
> associated concern.
>
> In a separate reply, the authors of
> draft-lz-bess-srv6-service-capability-02 pointed out that it provides a
> critique of bess-srv6-services which is similar to this discuss point. (The
> authors dropped the IESG from the cc, so I’m following up here instead of
> to their original note.)
>
> On first reading, the critique in draft-lz-bess-srv6-service-capability-02
> seems well argued and responsive to my question above about potential error
> modes. In section 3 of their draft, the authors provide a worked scenario
> where a VPN route carrying a SRv6 service SID using the Transposition
> scheme, if received by an MPLS-only PE, could result in 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi John,

Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI
> registry. Shouldn’t this be renamed? I mean, I guess it should have been
> renamed as of RFC 8365, but better late than never. I’m not sure quite what
> the name should become, but “MPLS-labeled” is manifestly wrong. Even
> “labeled” is wrong since the thing you’re stuffing in there isn’t a label.
> Since you’re the last one to touch it :-) if we can agree a better name for
> the SAFI I think it would be appropriate to add that to your IANA
> Considerations.
>

My suggestion would be: "VPN address & context"  or "Context & VPN address"

Thx,
R.
___
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)

[Robert Raszuk]

Joel,

There was a lot of effort by various vendors put in place to help automate
protection of the domain from getting any external packet to the
infrastructure addresses.

Typically I have seen two models in SPs:

* automatic ACL protection at the data plane for all infra targets
(sometimes with exceptions of ICMP)

* putting Internet into a VPN itself hence limiting to what comes from
Internet stays in the special VPN dedicated for it.

I have not seen much individual protection done at the L2 or L3 VPNs PEs to
selectively decapsulate. But it could be done too.

However all of this is about transport layer, while this draft is mainly
about service layer so to me this is out of topic if you see the layer
decoupling.

BESS :),
Robert.


On Thu, Feb 17, 2022 at 5:11 PM Joel M. Halpern  wrote:

> I would have to dig for it, but there is general guidance that nodes
> should not decapsulate IP tunnels that they don't know about.  (There
> are exceptions, such as LISP.  But neither GRE nor MPLS in UDP have such
> exceptions.)  Conceptually, SRv6 introduces a generic exception for SRv6
> SIDs within the limited domain.  But still says to check that the packet
> you are receiving at least claims to be from within the limited domain.
>
> This has nothing to do with sr-policy.
>
> Yours,
> Joel
>
> On 2/17/2022 11:06 AM, Robert Raszuk wrote:
> > Joel,
> >
> > But we are back to per src policy then right ?
> >
> > Frankly I never saw such a policy on egress PEs and I did see L3VPNs or
> > L2VPNs running over IP. The protection is applied on ingress you your
> > domain.
> >
> > Thx,
> > R.
> >
> >
> > On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern  > <mailto:j...@joelhalpern.com>> wrote:
> >
> > I would presume that the general policy (which does not apply to
> SRv6)
> > that nodes should not decapsulate  tunnel packets without
> configuration
> > or special exemption would mean that an arbitrary MPLS node will not
> > decapsualte a GRE packet and process its MPLS content.  Otherwise,
> all
> > tunnels become major security risks.
> >
> > Yours,
> > Joel
> >
> > On 2/17/2022 10:41 AM, Zhuangshunwan wrote:
> >  > Hi all,
> >  >
> >  > +1 for Robert.
> >  >
> >  > Yes, especially when MPLS in GRE or MPLS in UDP is deployed,
> packets
> >  > carrying MPLS labels can traverse all IP-reachable networks and
> > reach
> >  > remote PEs.
> >  >
> >  > BR,
> >  >
> >  > Shunwan
>
>  >
> >  > *From:*Robert Raszuk [mailto:rob...@raszuk.net
> > <mailto:rob...@raszuk.net>]
> >  > *Sent:* Thursday, February 17, 2022 11:28 PM
> >  > *To:* Warren Kumari mailto:war...@kumari.net
> >>
> >  > *Cc:* Ketan Talaulikar  > <mailto:ketant.i...@gmail.com>>; Andrew - IETF
> >  > ; Bocci, Matthew (Nokia - GB)
> >  > mailto:matthew.bo...@nokia.com>>;
> > draft-ietf-bess-srv6-servi...@ietf.org
> > <mailto:draft-ietf-bess-srv6-servi...@ietf.org>;
> >  > bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>; The IESG
> > mailto:i...@ietf.org>>; BESS  > <mailto:bess@ietf.org>>
> >  > *Subject:* Re: Warren Kumari's Discuss on
> >  > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
> >  >
> >  > Hi Warren,
> >  >
> >  > I am very sorry but I see folks are completely mixing transport
> > layer
> >  > and service layer.
> >  >
> >  > In RFC4364 you can use MPLS label for service demux and IP
> > transport to
> >  > get to remote egress PE via any IP network including Internet.
> >  >
> >  > There is nothing in L3VPNs like enabling MPLS on interface as
> > mandatory
> >  > prerequisite. Yes many folks are confused about this and I see
> > the same
> >  > confusion here. The service plane is completely separate from
> > transport
> >  > layer from day one.
> >  >
> >  > Kind regards,
> >  >
> >  > Robert
> >  >
>
>
___
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)

[Robert Raszuk]

Hi Warren,

I am very sorry but I see folks are completely mixing transport layer and
service layer.

In RFC4364 you can use MPLS label for service demux and IP transport to get
to remote egress PE via any IP network including Internet.

There is nothing in L3VPNs like enabling MPLS on interface as mandatory
prerequisite. Yes many folks are confused about this and I see the same
confusion here. The service plane is completely separate from transport
layer from day one.

Kind regards,
Robert








On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari  wrote:

>
>
> 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
>>>
>>>
>>>
>>>Durin

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi John,

As you have quoted my note in point #4 I feel that I need to comment on it.

So yes original discussions and major contributions of this work were
focusing on VPN use case and I admit when carefully re- reading it to find
some text there beyond VPN use case.

So we discussed it among co-authors. The point of adding 5.3 & 5.4 is
targeting the networks where Internet routes are not present at each node
and network uses summarization of infrastructure routes (no end to end /128
leaking in the IGP).

The text perhaps may require some clarification that use of SAFI 1 is left
for the operators to choose if the attribute should be attached to Internet
routes - when operator is offering an IP transit or it can be attached just
to next hops which are part of the infrastructure. Let's also not forget
that if this is IP transit in most networks you can reach all hops along
the path anyway (modulo transit SP/ISP policy).

I think major concern expressed from Warren was the potential compromise to
the VPNs when SID demuxing it would leak. Well as we know SAFI 128 or 70
are not public. Yes customer may advertise his routes to SAFI 1 and leak
but no one has control over it and it is orthogonal to what happens in the
SP network.

With that I think that #3 and #4 are no longer a concern.

Best regards,
Robert


On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-bess-srv6-services-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/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:
> --
>
> 1. The shepherd writeup for this document says “It also received an RTG DIR
> review and cross-reviewed with the IDR working group”. Searching in my IDR
> inbox and the IDR mailing list archives, I don’t find any sign of the
> cross-review — can you please point me to it?
>
> 2. One area of concern I would have hoped IDR might have looked into is,
> the
> document makes a creative use of the MPLS Label field of the NLRI to carry
> the
> Function part of the SID. This means the SID is effectively split across
> the
> NLRI and the Prefix-SID attribute. What are the potential error modes if
> the
> Prefix-SID attribute should be lost from the route, while the NLRI is
> retained?
>
> (An obvious way of addressing this particular concern would be to define a
> new
> NLRI type with the desired semantics, instead of creatively repurposing
> fields
> within an existing NLRI type contrary to their definitions. Such an NLRI
> type
> would, for example, presumably state in its specification that if it was
> received without an accompanying Prefix-SID attribute, that would
> constitute an
> error.)
>
> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
> discussion turned quickly to the assertion that no, they don’t, in VPN
> address
> families. Let’s accept that claim for the sake of conversation. It’s still
> the
> case that sometimes (often?) routes are distributed from VPN address
> families
> into the Global Internet table. When this is done, by default, all the path
> attributes come along for the ride. Anyone who thinks this is just a
> hypothetical case might want to look back to (for example) significant
> network
> outages that were caused around a decade ago by leakage of BGP Attribute
> 128
> (ATTR_SET, RFC 6368) into the global Internet.
>
> The SIDs contained in these if-they-were-to-leak routes potentially give an
> attacker a means of directing packets into a VPN customer’s internal
> network.
>
> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid
> [WG]
> consensus”; however, there doesn’t seem to be consensus even amongst the
> authors as to whether Sections 5.3 and 5.4 are appropriate. This is a
> fairly
> fundamental disagreement! An illustration of the disagreement is
> https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:
>
> “So I can see why some people may have thought oh since transport in SRv6
> comes
> for free let's load it with services in an attribute and be done. Yes I
> can see
> that flattening this make it potentially easier (one less SAFI to enable),
> *but
> I am not sure we have reached a broad agreement here.* This comes as a
> consequence of moving service prefixes from MP_REACH_NLRI (perhaps new
> format
> and new SAFI) to an attribute.”
>
> (Emphasis added.)
>
> It's of course possible for 

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

[Robert Raszuk]

Hi Andrew,

Most of what you say is true, so is my statement that MPLS labels are never
carried in SAFI 1 in BGP.

However, let me explain why I think a bit different view may work better
here ...

First let's clearly divide MPLS labels used for transport (which create
actual LSPs) from MPLS labels used for services (which are used to demux
packets at the egress PEs into appropriate context tables - typically VRFs
but not only (can be directly CEs too))

So the draft in the discussion is about overlay VPN services and therefore
the analogy made to MPLS labels are only related to SAFI 128 or SAFI 70.
Nothing here travels in unicast SAFI 1 nor in any IGP. So in the context of
this draft we should never allow to put the new attribute neither in SAFI 1
nor even SAFI 4.

But now comes the part which makes this discussion mangled ... unlike in
MPLS where LSPs need to be signalled in SRv6 you do not need any signalling
and IPv6 reachability is all that is needed for transport. So in SRv6 what
is in MPLS world signalled in LDP or RSVP-TE or SAFI 4 is indeed carried in
AFI 2 & SAFI 1.  /* SAFI 4 comes helpful when you build hierarchical LSPs
but in this discussion it is completely irrelevant. */

So I can see why some people may have thought oh since transport in SRv6
comes for free let's load it with services in an attribute and be done. Yes
I can see that flattening this make it potentially easier (one less SAFI to
enable), but I am not sure we have reached a broad agreement here. This
comes as a consequence of moving service prefixes from MP_REACH_NLRI
(perhaps new format and new SAFI) to an attribute.

Thx,
R.





On Sun, Feb 13, 2022 at 2:50 PM Andrew - IETF 
wrote:

> +1
>
>
>
> This is something I was a little confused about since its been referenced
> in these emails time and again, and I was wondering if I had missed
> something, but, I’ve checked to be 100%  certain, RFC8950 which is what
> this document refers to explicitly states that the NLRI encoding  of the
> destination must not change – and since the IPv4 NLRI leaves no provision
> for labels – and  makes it clear that SAFI 4 is used for MPLS – MPLS
> doesn’t fall into SAFI 1.
>
> In fact, what is described in 5.3 only results from the nature of SRv6, it
> states:
>
>
>
>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
>
>SRv6 Endpoint behavior of the SRv6 SID is entirely up to the
>
>originator of the advertisement.  In practice, the SRv6 Endpoint
>
>behavior is End.DX4 or End.DT4.
>
>
>
> Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over
> SRv6 core – which by correlation to 8950 is SAFI 1) and based on the
> wording of the above, this actually puts MPLS type functionality into SAFI
> 1 where it never was before, by using the SID as a normal address which is
> then dealt with as a SID inside the domain.  But no – this is not providing
> equal functionality for MPLS – this is extending MPLS style functionality
> into SAFI 1, which, if my reading of Warren’s discuss is accurate, is
> pretty much the essence of the problem.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, February 13, 2022 3:48 PM
> *To:* Gyan Mishra 
> *Cc:* Andrew - IETF ; BESS ;
> Bocci, Matthew (Nokia - GB) ; The IESG <
> i...@ietf.org>; Warren Kumari ; bess-cha...@ietf.org;
> draft-ietf-bess-srv6-servi...@ietf.org
> *Subject:* Re: [bess] Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
> Gyan,
>
>
>
> MPLS is never sent in SAFI 1.
>
>
>
> Thx,
> R.
>
>
>
> On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:
>
> Hi Robert
>
>
>
> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>
> Gyan,
>
>
>
> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
> encoding.  In this case using GRT transport underlay layer now carry’s the
> customer routes and that is what Warren and Andrew concern is as far as BGP
> leaks.
>
>
>
> I would have the same concern so would VPN customers. No one is selling L2
> or L3 VPN service to them distributing their reachability in the global
> routing table. They can do that all by themselves and there is lot's of
> really solid tools or products to do that already without being locked to a
> single telco.
>
>
>
> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
> look to use SRv6 for a variety of use cases. That’s my point as there
> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
> support.  Global Internet routing would not be the best use case for SAFI 1
&

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

[Robert Raszuk]

Gyan,

MPLS is never sent in SAFI 1.

Thx,
R.

On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:

> Hi Robert
>
> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>
>> Gyan,
>>
>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>>> encoding.  In this case using GRT transport underlay layer now carry’s the
>>> customer routes and that is what Warren and Andrew concern is as far as BGP
>>> leaks.
>>>
>>
>> I would have the same concern so would VPN customers. No one is selling
>> L2 or L3 VPN service to them distributing their reachability in the global
>> routing table. They can do that all by themselves and there is lot's of
>> really solid tools or products to do that already without being locked to a
>> single telco.
>>
>
> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
> look to use SRv6 for a variety of use cases. That’s my point as there
> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
> support.  Global Internet routing would not be the best use case for SAFI 1
> GRT due to the attack vector - agreed, but enterprise networks with
> internal customers where there is a trust level is a huge use case.
>
>>
>> So when GRT is used the same edge filtering protection mechanisms used
>>> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>>>
>>
>> Not possible. It is not about filtering ... it is all about using
>> globally routable SAFI vs private SAFIs to distribute customer's
>> reachability, IMO that should still be OTT only.
>>
>
> Gyan> As SRv6 source node is requirement to encapsulation with IPv6
> outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
> steering the security issue brought up related to 5.3 and 5.4 is not an
> issue requiring filtering per RFC 8402.  So routable and private SAFI
> scenario would be the same now due to encapsulation overlay for both.  Do
> you agree ?
>
>>
>> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
>>> tighten up verbiage as far securing the domain.
>>>
>>
>> BGP filtering or policy is in hands of many people. As has been proven
>> you can not tighten them strong enough not to leak. The only natural way to
>> tighten them is to use different plane to distribute private information
>> what in this context means at least different BGP SAFI.
>>
>> So no - I do not agree with your observations.
>>
>
>Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide
> complete parity with MPLS to support both SAFI 1 and 128. There  are plenty
> of use cases for SAFI 1 and it should be supported with SRv6.
>
>>
>> However I am for providing overlay reachability over global IPv6 Internet
>> to interconnect customer sites. But routing within those sites should not
>> be traversing Internet routers and using SAFI 1.
>>
>> Rgs,
>> Robert.
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
___
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)

[Robert Raszuk]

Gyan,

Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
> encoding.  In this case using GRT transport underlay layer now carry’s the
> customer routes and that is what Warren and Andrew concern is as far as BGP
> leaks.
>

I would have the same concern so would VPN customers. No one is selling L2
or L3 VPN service to them distributing their reachability in the global
routing table. They can do that all by themselves and there is lot's of
really solid tools or products to do that already without being locked to a
single telco.

So when GRT is used the same edge filtering protection mechanisms used
> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>

Not possible. It is not about filtering ... it is all about using globally
routable SAFI vs private SAFIs to distribute customer's reachability, IMO
that should still be OTT only.

I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
> tighten up verbiage as far securing the domain.
>

BGP filtering or policy is in hands of many people. As has been proven you
can not tighten them strong enough not to leak. The only natural way to
tighten them is to use different plane to distribute private information
what in this context means at least different BGP SAFI.

So no - I do not agree with your observations.

However I am for providing overlay reachability over global IPv6 Internet
to interconnect customer sites. But routing within those sites should not
be traversing Internet routers and using SAFI 1.

Rgs,
Robert.
___
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)

[Robert Raszuk]

Hi Andrew,

When I read Warren's note Iooked at this text from section 2 which says:

- - -

   The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
   SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
   services.

   o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
  SRv6 based L3 services.  It corresponds to the equivalent
  functionality provided by an MPLS Label when received with a Layer
  3 service route as defined in [RFC4364] [RFC4659] [RFC8950]
  [RFC9136].  Some SRv6 Endpoint behaviors which MAY be encoded, but
  not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.

   o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
  SRv6 based L2 services.  It corresponds to the equivalent
  functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)
  Route-Types as defined in [RFC7432].  Some SRv6 Endpoint behaviors
  which MAY be encoded, but not limited to, are End.DX2, End.DX2V,
  End.DT2U, End.DT2M etc.

   When an egress PE is enabled for BGP Services over SRv6 data-plane,
   it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
   TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
   defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364]
   [RFC9136] where applicable as described in Section 5 and Section 6.

   The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
   is outside the scope of this document.

- - -

This limits the overlay signalling to non global SAFIs mainly SAFI 128 and
SAFI 70.

To your note SAFI 4 is private and never exchanged in the wild. Also SAFI 2
is multicast which is out of scope of this draft.

The only thing which we need to sync on is indeed section 5.4 and use of
global IPv6 AFI 2 & SAFI 1

Many thx,
R.




On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF 
wrote:

> Robert,
>
>
>
> I have to say that I have very similar readings on parts of the draft.
>
>
>
> Let’s look at it –
>
>
>
> 5.1 uses the IPv4-VPN NLRI – That would seem to indicate AFI 1 / SAFI 4
>
> 5.2 – Uses AFI 2 / SAFI 4 from my reading
>
> 5.3 – According to RFC8950 – allows advertisement over SAFI 1, 2 or 4
>
> 5.4 – To my reading – very much refers to AFI 2 / SAFI 1.
>
>
>
> I would agree if this document limited itself to 5.1 and 5.2 – it doesn’t
> – and therefore I have to agree with the thoughts expressed in Warrens
> Discuss.  If I am wrong about 5.3 and 5.4, let’s chat and help me
> understand this better, and then lets potentially see if we can work up
> some wording that would clarify this if that is what is required.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* iesg  *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari 
> *Cc:* Bocci, Matthew (Nokia - GB) ;
> draft-ietf-bess-srv6-servi...@ietf.org; bess-cha...@ietf.org; The IESG <
> i...@ietf.org>; BESS 
> *Subject:* Re: Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
> Hi Warren,
>
>
>
> Thank you for your Discuss. But before we start discussing it perhaps it
> would be good to align on what this document really defines as I am sensing
> from your description there can be some disconnect (modulo some text may be
> indeed misleading in the draft).
>
>
>
> You said:
>
>
>
> > 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.
>
>
>
> I think the term BGP is used here a bit too broadly.
>
>
>
> Leaks do happen but only within global AFI/SAFIs. This draft defines
> extensions for L3VPN and L2VPNs SAFIs which are not used to peer outside of
> a domain, collection of domains under same administration +
> of course inter-as also could happen.
>
>
>
> With that being said I do not see risk that due to leaking there could be
> a situation where customer networks are exposed in any way externally -
> leaving alone that to even get at the transport level to the customer
> facing PE is also filtered and never allowed from outside. But this is out
> of scope of this document as here the focus is not on underlay but overlay.
>
>
>
> Now when I re-read this I see why there is a little piece perhaps
> misleading. The draft makes a claim that it is applicable to RFC8950 which
> defines use of NHv6 with both unicast and VPN AFs. That needs to be made
> clear that it is applicable to the latter only. If other co-authors believe
> this is applicable to the former your DISCUSS section would indeed be
> valid.
>
>
>
> Many thx,
>
> R.
>
&

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

[Robert Raszuk]

Hi Warren,

Thank you for your Discuss. But before we start discussing it perhaps it
would be good to align on what this document really defines as I am sensing
from your description there can be some disconnect (modulo some text may be
indeed misleading in the draft).

You said:

> 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.

I think the term BGP is used here a bit too broadly.

Leaks do happen but only within global AFI/SAFIs. This draft defines
extensions for L3VPN and L2VPNs SAFIs which are not used to peer outside of
a domain, collection of domains under same administration +
of course inter-as also could happen.

With that being said I do not see risk that due to leaking there could be a
situation where customer networks are exposed in any way externally -
leaving alone that to even get at the transport level to the customer
facing PE is also filtered and never allowed from outside. But this is out
of scope of this document as here the focus is not on underlay but overlay.

Now when I re-read this I see why there is a little piece perhaps
misleading. The draft makes a claim that it is applicable to RFC8950 which
defines use of NHv6 with both unicast and VPN AFs. That needs to be made
clear that it is applicable to the latter only. If other co-authors believe
this is applicable to the former your DISCUSS section would indeed be
valid.

Many thx,
R.




On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:

> 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

Re: [bess] [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Robert Raszuk]

IMO we could add to the draft a statement that implementation MUST/SHOULD
support fallback to any available forwarding plane. But I am not sure if
this will not turn out against some implementations which may have problem
with that.

Order of such fallback is a policy/cfg decision.

Likewise before considering any forwarding plane use a data plane
reachability to the endpoint must be validated/tested - that should go
without saying but as we know there are implementations which only rely on
a control plane which is proven in action to be a rather poor method. There
are number of reasons where presence in RIB/inet does is not the same as
data plane reachability .

Thx,
Robert.



On Thu, Jul 22, 2021 at 12:41 PM Ketan Talaulikar (ketant) 
wrote:

> Hi Salih,
>
>
>
> The preference for steering over SR Policy applies to both SR-MPLS and
> SRv6. So we are covered from that perspective.
>
>
>
> I get the impression that this email discussion thread about “fallback” is
> about when sending over a non-SR Policy based steering mechanism. That too,
> I get the impression is that it is specifically about the scenario where
> there might not be a reachability via IGP FlexAlgo for the egress PE’s
> Locator from which the SRv6 service SID is allocated from.
>
>
>
> To me (and few other WG members), an alternate path or tunnel mechanism to
> reach the egress PE is something that is deployment specific and can be
> implemented via various mechanisms. While Shraddha has proposed a mechanism
> for this, I’ve also described a new other ways – there will be more. While
> the draft currently does not discuss this, it does not preclude any of
> these mechanisms either.
>
>
>
> The draft is currently done with WGLC and is in our AD (Martin’s) Q for
> his review. The question for the WG is if we do really need to clarify
> something about this “FlexAlgo fallback” case and if so, come up with some
> proposed text. IMHO details of such fallback mechanisms are outside the
> scope of this document and we can say so if that helps.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A 
> *Sent:* 22 July 2021 15:35
> *To:* Ketan Talaulikar (ketant) ; Rajesh M <
> mraj...@juniper.net>
> *Cc:* draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org;
> bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Thanks, Ketan.
>
>
>
> This indicates a preference for steering over SR Policy while using color
> extended community.
>
> Then specify color only bits etc modes for specifying fallbacks if
> required. Currently it doesn’t talk about flex (but mention mostly IGP path
> to the next-hop N) and hence it need not necessarily pick SRv6 flex algo
> paths.
>
>
>
> Are we suggesting only if some indication comes the fallback will happen
> to flex algo? OR can we define an order like:
>
> SRv6 policy (using BGP NH)
>
> SRv6 Flex (using SRv6 Service SID)
>
>
>
> and a mention of local policy which can override if required.
>
>
>
> Regards,
>
> Salih
>
> *From: *"Ketan Talaulikar (ketant)" 
> *Date: *Thursday, July 22, 2021 at 2:25 PM
> *To: *Salih K A , Rajesh M 
> *Cc: *"draft-ietf-bess-srv6-servi...@ietf.org" <
> draft-ietf-bess-srv6-servi...@ietf.org>, "spr...@ietf.org" <
> spr...@ietf.org>, "bess@ietf.org" 
> *Subject: *RE: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Salih,
>
>
>
> Could you please check the following regarding the choice/fallback when
> using SR Policy based steering?
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4
> 
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8
> 
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Salih K A 
> *Sent:* 22 July 2021 14:02
> *To:* Ketan Talaulikar (ketant) ;
> Rajesh M 
> *Cc:* draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org;
> bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> Hi Ketan,
>
>
>
> 1 clarification query:
>
>
>
> With flex algo and SRTE policies, service routes can carry color extended
> communities.
>
> Now for the ingress, how to decide whether to resolve over SRv6 Service
> SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)?
>
> In a domain both can be present & operators may want fallbacks as well if
> one is not available. So, I think it’s better to clarify that to avoid
> ambiguity.
>
>
>
> Thanks,
> Salih
>
> *From: *spring  

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Robert Raszuk]

Jim,

The "policy" I had in mind was a simple cfg switch "fallback global" for
any SRv6 service originally set to say run over different IGP topology. Or
perhaps if more then two options are available, list the chain of
forwarding tables/topologies to be used as transport for a given SRv6
service.

Implementation may get even smarter and allow operator to set performance
based triggers to select such forwarding topologies from a flat pool.

If Shraddha has the same in mind not sure there is much to elaborate on
here :)

Best,
R.

On Tue, Jul 20, 2021 at 12:20 PM UTTARO, JAMES  wrote:

> *Comments In-Line..*
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* spring  *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, July 20, 2021 5:56 AM
> *To:* Robert Raszuk 
> *Cc:* spr...@ietf.org; bess@ietf.org
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
>
>
> Good to know the intention is to support fallback for Srv6.
>
>
>
> The way current text is written, it implies service SID is always in the 
> destination address.
>
> And hence service SID should be resolvable. This is not the case when a 
> service SID
>
> Corresponding to flex-algo wants to fallback on best effort services. The 
> destination address cannot carry
>
> Service SID for fallback cases and hence it need not be resolved.
>
>
>
> I suggest that the authors add below text in bold to the draft.
>
>
>
>
>
> “When providing best-effort connectivity *or flex-algo connectivity* to the 
> egress PE,
>
> the ingress PE encapsulates the payload in an outer IPv6 header where the 
> destination
>
> address is the SRv6 Service SID associated with the related BGP route update.
>
>  Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 
> Service SID
>
>  before considering the received prefix for the BGP best path computation.
>
> “
>
> “*In some cases a service prefix intending to use flex-algo paths may want 
> fallback on*
>
> *best effort paths when a flex-algo path isn’t available. The fallback 
> behavior *
>
> *SHOULD be governed by local policies.   *
>
> *[Jim U>] It would be helpful to provide an example of local policies and how 
> would/should said local policies be applied across a heterogeneous network.*
>
> *The destination address SHOULD contain the best-effort locator based END SID 
> *
>
> *of the egress PE and the SRH SHOULD contain the service SID. Service SID *
>
> *resolvability SHOULD NOT be checked on the ingress for this case*.”
>
>
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, July 20, 2021 12:04 PM
> *To:* Shraddha Hegde 
> *Cc:* spr...@ietf.org; bess@ietf.org
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Shraddha,
>
>
>
> > that authors don’t intend to support any form of tunnelling for SRv6
>
> > because it is not optimal. Is that the right read?
>
>
>
> Quite the opposite. It is the local operator's choice (not the draft
> authors) to decide to fall back to best effort or to drop.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde 
> wrote:
>
> Robert,
>
>
>
> What do you mean by SR? is it SR-MPLS or SRv6.
>
> My question is about draft-ietf-bess-srv6-services and applies only to
> SRv6.
>
>
>
> Let me repeat the question.
>
> Do the authors intend to support the case of fallback from SRv6 flex-algo
> to SRv6 best effort transport for SRv6
>
> Services or not?
>
>
>
> From your vague answer it appears that authors don’t intend to support any
> form of tunnelling for SRv6
>
> because it is not optimal. Is that the right read?
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde 
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> bruno.decra...@orange.com; spr...@ietf.org; b...@ans.net; Srihari Sangli <
> ssan...@juniper.net>; bess@ietf.org
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Robert Raszuk]

Shraddha,

> that authors don’t intend to support any form of tunnelling for SRv6

> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft
authors) to decide to fall back to best effort or to drop.

Thx,
R.



On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde  wrote:

> Robert,
>
>
>
> What do you mean by SR? is it SR-MPLS or SRv6.
>
> My question is about draft-ietf-bess-srv6-services and applies only to
> SRv6.
>
>
>
> Let me repeat the question.
>
> Do the authors intend to support the case of fallback from SRv6 flex-algo
> to SRv6 best effort transport for SRv6
>
> Services or not?
>
>
>
> From your vague answer it appears that authors don’t intend to support any
> form of tunnelling for SRv6
>
> because it is not optimal. Is that the right read?
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde 
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> bruno.decra...@orange.com; spr...@ietf.org; b...@ans.net; Srihari Sangli <
> ssan...@juniper.net>; bess@ietf.org
> *Subject:* Re: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Shraddha,
>
>
>
> In an SR network fallback to best effort will also result in encapsulated
> forwarding using SR. It may not be as optimal service wise as using
> flex-algo, but this is form of tunneling. Hence I don't think your comment
> applies.
>
>
>
> Note that operator may also choose to use IP tunneling for best effort
> forwarding if SR best effort forwarding is not supported or enabled.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
> wrote:
>
> Hi Authors,
>
>
>
> There is a possibility of a usecase that wants to use flex-algo paths if
> available and if flex-algo paths
>
> Are not available use best effort paths.
>
>
>
> “When providing best-effort connectivity to the egress PE, the ingress
>
>PE encapsulates the payload in an outer IPv6 header where the
>
>destination address is the SRv6 Service SID associated with the
>
>related BGP route update.  Therefore, the ingress PE SHOULD perform
>
>resolvability check for the SRv6 Service SID before considering the
>
>received prefix for the BGP best path computation.
>
> “
>
>
>
> The current text says for best effort tunnels Srv6 service SID resolution
> SHOULD be checked and
>
> I am told that (from previous mailing list exchanges) authors intend to
> update the text to make it applicable for flex-algo connectivity  as well.
>
>
>
> It is not possible to support fallback on best effort tunnels if flex-algo
> SRv6 service SIDs have to be resolved.
>
> It is possible to support fallback to best effort in SRv6 if packets can
> be tunneled to egress PE  (destination address being PE’s best effort END
> SID and service SID in the SRH)and
>
> then do a service SID lookup on egress, in which case there is no need to
> resolve the SRv6 service SIDs on the ingress.
>
>
>
> It is not clear whether the authors intend to support these kind of
> tunnelling to egress cases for
>
> Best effort and flex-algo transport. If it not going to be supported, pls
> add text indicating clearly
>
> Tunnelling is not required to be supported and hence Fallback to best
> effort  is also not supported.
>
>
>
> If that is not the intention, Its reasonable to update the text to
> indicate SRv6 service SIDs need not be resolved
>
> If the ingress is tunneling the packet.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Aissaoui,
> Mustapha (Nokia - CA/Ottawa)
> *Sent:* Monday, July 19, 2021 7:34 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Rajesh M ; Rajesh M  40juniper@dmarc.ietf.org>; Ketan Talaulikar (ketant) ;
> gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) ;
> rob...@raszuk.net; bruno.decra...@orange.com
> *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli ;
> bess@ietf.org; Shraddha Hegde 
> *Subject:* Re: [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Rajesh,
>

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Robert Raszuk]

I agree with Jorge..

In fact I find the tone of the comment to be very inappropriate:

*> In case of best effort/flex algo we must mandate user to set
corresponding locator as BGP nexthop for srv6 routes.*

*No we MUST not mandate anything to the user. *

*We MUST provide flexibility to address all deployment cases user may
have. *

*Best,*
*R.*



On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Hi Rajesh,
>
>
>
> The draft is written so that the next-hop address MAY be covered by the
> locator, but there are cases in which the next-hop address is not part of
> the locator prefix, and there are implementations already allowing that, so
> I don’t agree the document should mandate what you are suggesting.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Rajesh M 
> *Date: *Monday, July 19, 2021 at 3:24 PM
> *To: *Rajesh M , Ketan Talaulikar
> (ketant) , gdawra.i...@gmail.com ,
> Clarence Filsfils (cfilsfil) , rob...@raszuk.net <
> rob...@raszuk.net>, bruno.decra...@orange.com ,
> Rabadan, Jorge (Nokia - US/Mountain View) 
> *Cc: *spr...@ietf.org , b...@ans.net ,
> Shraddha Hegde , bess@ietf.org ,
> Srihari Sangli 
> *Subject: *RE: SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
> Hi Authors,
>
>
>
> Please respond.
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring  *On Behalf Of *Rajesh M
> *Sent:* Thursday, July 15, 2021 4:36 PM
> *To:* Ketan Talaulikar (ketant) ; gdawra.i...@gmail.com;
> Clarence Filsfils (cfilsfil) ; rob...@raszuk.net;
> bruno.decra...@orange.com; jorge.raba...@nokia.com
> *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde ;
> bess@ietf.org
> *Subject:* [spring] SRv6 BGP based Overlay Services
> (draft-ietf-bess-srv6-services-07)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi All,
>
>
>
> As per this draft, this is how resolution must work.
>
>
>
> 1)For Non Intent service Route:
>
> if BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding.
>
>
>
> 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR
> Policy):
>
> BGP next hop is not reachable return.
>
> Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if
> successfully resolves then return.
>
> Resolve BGP next hop for forwarding (in case above is not success).
>
>
>
>
>
> *Using Service SID (overlay),for resolution is definitely not recommended.*
>
>
>
> *Instead in case of srv6, we always resolve on BGP nexthop. This will be
> in line with BGP legacy.*
>
> *In case of best effort/flex algo we must mandate user to set
> corresponding locator as BGP nexthop for srv6 routes.*
>
> *I think this is a reasonable mandate.*
>
>
>
> Thanks
>
> Rajesh
>
>
>
> Juniper Business Use Only
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] BGP CAR SAFI NLRI format

[Robert Raszuk]

Hey Srihari,

While you are right in the notion of original BGP spec I think the
definition of what is key for someone remains very loose.

Just take a look at RFC5575 where key is defined as opaque bit string :)

   This NLRI is treated as an opaque bit string prefix by
   BGP.  Each bit string identifies a key to a database entry with which
   a set of attributes can be associated.


Best,

Robert



On Wed, Jul 14, 2021 at 12:35 PM Srihari Sangli  wrote:

> Hello,
>
>
>
> Looking at the archives on this topic, there was a small discussion about
> the structure of the NLRI as proposed in the BGP CAR draft. The
> conversation was not conclusive and here’s my thought and a question
> related to the topic.
>
>
>
> While the proposed NLRI format enables NLRI types to be encoded and
> provides extensibility, it also lists the key and non-key fields. If we go
> down this path, there may be a tendency to add more fields into the NLRI.
> While ‘Type-specific Key Fields’ may be justifiable (for obvious reasons of
> identifying the NLRI), the ‘Type-specific Non-Key Fields’ has a potential
> to grow.
>
>
>
> Also, this is a departure from base BGP specification of NLRI and
> attributes where attributes carry the common information and non-key
> fields. Am wondering if the authors have done more investigation on this.
> Thanks.
>
>
>
> srihari…
>
>
>
> Juniper Business Use Only
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Robert Raszuk]

Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP.
It does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just
ask for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's
bw across few EBGP hops in the DC. Today there is no way to do so unless
you want to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather
poorly for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner  wrote:

> Jeff,
>
> Actually, the way this draft is written, and how the implementations I'm
> aware of are implemented, this is not really a transitive community. It is
> a new community that is being generated on the AS boundary.
> The community value is not carried over, but is calculated based on an
> cumulative value of other received communities, and then advertised as a
> new value across the AS boundary.
>
> Tnx,
> Arie
>
> On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
> wrote:
>
>> Hi,
>>
>> I support adoption of the draft as Informational, please note, that
>> request to change transitivity characteristics of the community is
>> requested in another draft.
>> Gyan  - please note, while pretty much every vendor has implemented the
>> community and relevant data-plane constructs, initial draft defines the
>> community as non transititive, some vendors have followed that while some
>> other have implemented it a transitive (to support obvious use case - eBGP
>> in DC).
>>
>>
>> Cheers,
>> Jeff
>> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org>, wrote:
>>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Robert Raszuk]

Gyan,

It is always helpful to an assessment into right scale.

Yes if you take few flows perhaps even a few big ones may suffer from
polarization. But the feature here is about hashing millions of micro
flows. With that in mind polarization effects are insignificant at
decent operational scale.

I support this draft.

Cheers,
Robert

PS. Also keep in mind that for handling elephant flows there are bunch of
TE like solutions in place which can be used which in turn give you very
fine control.

On Tue, May 25, 2021 at 9:23 AM Gyan Mishra  wrote:

>
> Hi Satya
>
> I read the draft and have a few questions.
>
> IPv4 does not support per flow per packet load balancing as all packets
> belonging to the same flow must hash to the same path to prevent out of
> order packets and thus is subject to polarization of flows as high
> bandwidth flows may hash to the same path and low bandwidth flows as well
> to the same path resulting in very uneven load balancing.  Do to this issue
> it does not make either iBGP or eBGP can really benefit from link bandwidth
> extended community weight based load sharing.
>
> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
> generated 20 byte key input to hash function results in uniform 50/50 load
> balancing over EGP or IGP ECMP paths.
>
> I think it maybe a good idea to reference the IPv4 polarization issue with
> flow based load balancing and that only with IPv6 flow label can true 50/50
> uniform load balancing be achieved.
>
> I noticed that the normative draft referenced was adopted but has not
> progressed.
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>
> Has the draft been implemented by Cisco or any other vendors ?
>
> Kind Regards
>
> Gyan
>
>
> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi John,

The way I understood this is intending to work in practice is simply to
create IBGP session between GW1 & GW2,

If we have this IBGP session then there are two cases:

* we receive route to X from peer GW so we know peer GW can reach X hence
it is safe to advertise X with both GWs as NHs
* we send route to X to peer GW so we know that peer GW can reach X (at
least via sender's GW) hence it is again ok to  advertise X with both GWs
as NHs

Seems like this logic can solve your question ...

But good catch :)

Cheers,
Robert





On Fri, May 14, 2021 at 10:12 PM John Scudder  wrote:

> Hi Adrian,
>
> Thanks for your reply. Pressed for time at the moment but one partial
> response:
>
> On May 14, 2021, at 1:04 PM, Adrian Farrel  wrote:
>
> Agree with you that "stuff happens." I think that what you have described
> is a window not a permanent situation.
> When GW2 knows it can't reach X any more, it will stop advertising X, and
> GW1 will receive that and will update what it advertises on behalf of GW2.
>
>
> Ah, perhaps I have badly misunderstood the way this works. I had thought
> it went something like this:
>
> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
> - GW1 knows the set S of internal prefixes it can reach
> - GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel
> attribute
>
> In the description above, there’s no notion of GW2 telling GW1 what
> internal prefixes GW2 can reach, or GW1 caring.  Now I suppose you are
> telling me that it goes:
>
> - GW1 knows it can reach GW2 because of GW2’s auto discovery route
> - GW1 knows the full set of prefixes GW2 can reach. _How does it know
> this?_
> - GW1 constructs each advertisement listing only the correct set of
> gateways in the tunnel attribute
>
> The key question is the one I’ve highlighted: how does GW1 come to know
> GW2’s internally-reachable prefixes? I didn’t notice any of this in the
> spec. Maybe it was just my sloppy reading, I’ll look again.
>
> Further, if GW1 can no longer receive advertisements from GW2 then it will
> stop advertising on behalf of GW2.
>
>
> Yes, that’s understood, but I was positing a case where just because GW1
> can reach GW2 stably, and just because GW1 can reach X stably, it does not
> imply GW2 can reach X.
>
> —John
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Robert Raszuk]

Hi Matthew & Stephane,



I support the publication of this draft as standards track RFC.


As a co-author, I am not aware of any undisclosed IPR(s).


Thank you,

Robert



On Mon, Nov 30, 2020 at 6:15 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email starts a two-week working group last call for 
> draft-ietf-bess-srv6-services-05
> [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a standards track
> RFC.
>
>
>
> This poll runs until Monday 14th December 2020.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an Author or a Contributor of this document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
> There is currently one IPR disclosure.
>
>
>
> In addition, we are polling for knowledge of implementations of this
> draft, per the BESS policy in [2].
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR

[Robert Raszuk]

Hi,

> [SLI] It could work if: we prevent usage of RTC for these families

Actually I am not sure we need to prevent anything. Honestly I would leave
it for the proper operator's configuration.

RTC is not something on by default in any AFI/SAFI.

Thx a lot,
R.



On Mon, Jun 8, 2020 at 4:48 PM  wrote:

> Hi Robert,
>
>
>
> Thanks for your feedback.
>
> Please find some comments inline.
>
>
>
> Stephane
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* lundi 8 juin 2020 11:55
> *To:* slitkows.i...@gmail.com
> *Cc:* idr@ietf. org ; BESS 
> *Subject:* Re: [bess] FW: Closing on Stephane's open issue with
> draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
>
>
>
> Stephane,
>
>
>
> Two points ..
>
>
>
>1. It is not clear to me that draft-ietf-bess-datacenter-gateway
>recommends to use RTC for anything - do they ? If not there is no
>issue.
>
> [SLI] Right, but nothing prevents someone to activate it or it can be
> activated “by inheritance” if sessions already runs VPNv4 for instance with
> RTC.
>
>
>
>1. Also note that RTC can be enabled on a per AF basis hence even if
>you use it say for SAFI 128 you do not need to use it for SAFI 1.
>
> [SLI] RFC4684 is AFI/SAFI agnostic. I’m not aware of per-AFI/SAFI scoping
> of RT membership from an implementation point of view. You can do it by
> splitting sessions usually.
>
>
>
> [SLI] It could work if: we prevent usage of RTC for these families, or we
> specify the default behavior of RTC for AFI/SAFI 1/1, 2/1 when there is no
> RT (distribute routes that don’t have an RT).
>
>
>
>
>
> As a general comment I do not see any issues using RTs on non VPN SAFIs.
>
>
>
> Thx,,
>
> R.
>
>
>
> On Mon, Jun 8, 2020 at 10:34 AM  wrote:
>
> Hi IDR WG,
>
> We have a draft that was on WGLC which introduces the usage of Route
> Targets
> on Internet address families to allow automated filtering of gateway
> routes.
> I raised a concern on a potential issue happening when Route Target
> constraint is deployed on these sessions.
>
> Internet address families don't use RTs today, and are propagated following
> the BGP propagation rules. When applying an RT and when having RTC deployed
> on the session (RTC not being family aware), propagation of Internet routes
> that don't have an RT may be stopped because of the behavior defined in
> draft-ietf-idr-rtc-no-rt. This will so break the existing default behavior
> of Internet SAFIs.
>
> We would like to get IDR's feedback on this topic.
>
> Thanks,
>
> Stephane
> BESS co-chair
>
>
> -Original Message-
> From: Adrian Farrel 
> Sent: jeudi 4 juin 2020 19:31
> To: slitkows.i...@gmail.com
> Cc: bess-cha...@ietf.org; bess@ietf.org;
> draft-ietf-bess-datacenter-gate...@ietf.org
> Subject: Closing on Stephane's open issue with
> draft-ietf-bess-datacenter-gateway
>
> Hi,
>
> John and I had a chat today about what we perceive is Stephane's open
> issue.
>
> What we think the concern is is that we are using RTs in conjunction with
> normal (i.e., non-VPN) routes. We do this to allow gateways to filter their
> imports based on the RT that applies to the SR domain that it serves.
>
> An option was to use the Route Origin extended community instead.
>
> RFC 4360, which introduces both the Route Target and the Route Origin
> extended communities and gives some guidance. Loosely expressed, the RT
> says
> which routers should import, the RO says which routers have advertised. In
> both cases, the text suggests that "One possible use of the community is
> specified in RFC4364" which implies that there are other acceptable uses.
>
> 4364 implies that the RO is used "to uniquely identify the set of routes
> learned from a particular site." That is (my words), to apply a filter on
> top of the RT to prevent re-import by a site of routes that match the RT
> and
> that were advertised by other entry points to the site. Indeed, the RO
> would
> seem to be used (in the 4364 case) only when the RT is also in use.
>
> We appreciate that the distinction is pretty delicate, but we think we are
> right to use RT in this case because we are filtering to import, not to
> avoid importing. Furthermore, if we used the RO then, to be consistent with
> 4364, we would still be using the RT anyway.
>
> That, we think, disposes of the "RT or RO?" question.
>
> Now, we can go back to the original formulation of the question: is it OK
> to
> use RT with "non-VPN IP addresses"? Well, we consulted around a bit
> privately amongst some BGP experts, and we couldn't find a

Re: [bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR

[Robert Raszuk]

Stephane,

Two points ..

1. It is not clear to me that draft-ietf-bess-datacenter-gateway recommends
to use RTC for anything - do they ? If not there is no issue.

2. Also note that RTC can be enabled on a per AF basis hence even if you
use it say for SAFI 128 you do not need to use it for SAFI 1.

As a general comment I do not see any issues using RTs on non VPN SAFIs.

Thx,,
R.

On Mon, Jun 8, 2020 at 10:34 AM  wrote:

> Hi IDR WG,
>
> We have a draft that was on WGLC which introduces the usage of Route
> Targets
> on Internet address families to allow automated filtering of gateway
> routes.
> I raised a concern on a potential issue happening when Route Target
> constraint is deployed on these sessions.
>
> Internet address families don't use RTs today, and are propagated following
> the BGP propagation rules. When applying an RT and when having RTC deployed
> on the session (RTC not being family aware), propagation of Internet routes
> that don't have an RT may be stopped because of the behavior defined in
> draft-ietf-idr-rtc-no-rt. This will so break the existing default behavior
> of Internet SAFIs.
>
> We would like to get IDR's feedback on this topic.
>
> Thanks,
>
> Stephane
> BESS co-chair
>
>
> -Original Message-
> From: Adrian Farrel 
> Sent: jeudi 4 juin 2020 19:31
> To: slitkows.i...@gmail.com
> Cc: bess-cha...@ietf.org; bess@ietf.org;
> draft-ietf-bess-datacenter-gate...@ietf.org
> Subject: Closing on Stephane's open issue with
> draft-ietf-bess-datacenter-gateway
>
> Hi,
>
> John and I had a chat today about what we perceive is Stephane's open
> issue.
>
> What we think the concern is is that we are using RTs in conjunction with
> normal (i.e., non-VPN) routes. We do this to allow gateways to filter their
> imports based on the RT that applies to the SR domain that it serves.
>
> An option was to use the Route Origin extended community instead.
>
> RFC 4360, which introduces both the Route Target and the Route Origin
> extended communities and gives some guidance. Loosely expressed, the RT
> says
> which routers should import, the RO says which routers have advertised. In
> both cases, the text suggests that "One possible use of the community is
> specified in RFC4364" which implies that there are other acceptable uses.
>
> 4364 implies that the RO is used "to uniquely identify the set of routes
> learned from a particular site." That is (my words), to apply a filter on
> top of the RT to prevent re-import by a site of routes that match the RT
> and
> that were advertised by other entry points to the site. Indeed, the RO
> would
> seem to be used (in the 4364 case) only when the RT is also in use.
>
> We appreciate that the distinction is pretty delicate, but we think we are
> right to use RT in this case because we are filtering to import, not to
> avoid importing. Furthermore, if we used the RO then, to be consistent with
> 4364, we would still be using the RT anyway.
>
> That, we think, disposes of the "RT or RO?" question.
>
> Now, we can go back to the original formulation of the question: is it OK
> to
> use RT with "non-VPN IP addresses"? Well, we consulted around a bit
> privately amongst some BGP experts, and we couldn't find anyone to say it
> was actually a problem. And (of course) no one raised the issue in WG last
> call - but Matthew might claim that is because the document was only
> lightly
> reviewed, and Stephane might claim that this is because he had already
> raised the point. Obviously, some of the authors know a bit about BGP, and
> Eric was a lead author on 4364 and drove a lot of the details of what we
> wrote.
>
> Two points in closing:
> - If someone can show that we break something, we will have to fix it.
> - If the chairs want to run this point past IDR and BESS explicitly, that
> would be fine.
>
> Hope this helps.
>
> Best,
> Adrian
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway

[Robert Raszuk]

Stephane,

Two points ..

1. It is not clear to me that draft-ietf-bess-datacenter-gateway recommends
to use RTC for anything - do they ? If not there is no issue.

2. Also note that RTC can be enabled on a per AF basis hence even if you
use it say for SAFI 128 you do not need to use it for SAFI 1.

As a general comment I do not see any issues using RTs on non VPN SAFIs.

Thx,,
R.


On Mon, Jun 8, 2020 at 10:26 AM  wrote:

> Hi Adrian,
>
> My point is really tied to what will happen when RTC is enabled
> (considering
> draft-ietf-idr-rtc-no-rt). The behavior will be to drop the routes that
> don't have an RT which will break existing Internet families behavior.
> " When RTC is applied, on a particular BGP session, to routes of other
>address families, the default behavior MUST be that routes without
>any RTs are not distributed on that session.  This default "default
>behavior" applies to all AFI/SAFIs for which a different default
>behavior has not been defined."
>
> Let me run this to IDR to get their feedback (as draft-ietf-idr-rtc-no-rt
> is
> owned by IDR).
>
> Stephane
>
> -Original Message-
> From: Adrian Farrel 
> Sent: jeudi 4 juin 2020 19:31
> To: slitkows.i...@gmail.com
> Cc: bess-cha...@ietf.org; bess@ietf.org;
> draft-ietf-bess-datacenter-gate...@ietf.org
> Subject: Closing on Stephane's open issue with
> draft-ietf-bess-datacenter-gateway
>
> Hi,
>
> John and I had a chat today about what we perceive is Stephane's open
> issue.
>
> What we think the concern is is that we are using RTs in conjunction with
> normal (i.e., non-VPN) routes. We do this to allow gateways to filter their
> imports based on the RT that applies to the SR domain that it serves.
>
> An option was to use the Route Origin extended community instead.
>
> RFC 4360, which introduces both the Route Target and the Route Origin
> extended communities and gives some guidance. Loosely expressed, the RT
> says
> which routers should import, the RO says which routers have advertised. In
> both cases, the text suggests that "One possible use of the community is
> specified in RFC4364" which implies that there are other acceptable uses.
>
> 4364 implies that the RO is used "to uniquely identify the set of routes
> learned from a particular site." That is (my words), to apply a filter on
> top of the RT to prevent re-import by a site of routes that match the RT
> and
> that were advertised by other entry points to the site. Indeed, the RO
> would
> seem to be used (in the 4364 case) only when the RT is also in use.
>
> We appreciate that the distinction is pretty delicate, but we think we are
> right to use RT in this case because we are filtering to import, not to
> avoid importing. Furthermore, if we used the RO then, to be consistent with
> 4364, we would still be using the RT anyway.
>
> That, we think, disposes of the "RT or RO?" question.
>
> Now, we can go back to the original formulation of the question: is it OK
> to
> use RT with "non-VPN IP addresses"? Well, we consulted around a bit
> privately amongst some BGP experts, and we couldn't find anyone to say it
> was actually a problem. And (of course) no one raised the issue in WG last
> call - but Matthew might claim that is because the document was only
> lightly
> reviewed, and Stephane might claim that this is because he had already
> raised the point. Obviously, some of the authors know a bit about BGP, and
> Eric was a lead author on 4364 and drove a lot of the details of what we
> wrote.
>
> Two points in closing:
> - If someone can show that we break something, we will have to fix it.
> - If the chairs want to run this point past IDR and BESS explicitly, that
> would be fine.
>
> Hope this helps.
>
> Best,
> Adrian
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] XXCs

[Robert Raszuk]

Hi Jim,

Yes the topic is related to how multiple ASes under one administrative
umbrella can operate BGP.

But I must say that there are two fundamental approaches:

a) the one as you described in the OAD draft defining the ATTR_SET_STACK
attribute - sort of being an Eiffle Tower of what needs to be carried
across.

b) the other option is to decouple the problem into two sub functions:
 b.1 - make those ASNs operating under same administration aware of
each other by cfg
 b.2 - make new transitive rule to allow passing under same
administration.

I just proposed b.

Jakob proposed c) which is yet one more option to define set of reserved
values (could be ASN or a prefix for easy ACL) to indicate within given
attribute the scope of propagation when ingress policy allows. I find it
much more complex and error prone as compared with (b)

Thx,
R.







On Wed, Apr 8, 2020 at 4:53 PM UTTARO, JAMES  wrote:

> *Not sure if the intention here intersects with what I had in mind in
> 2012.. Pradosh, Saikat and I created a draft that introduced the notion of
> OAD ( One Administrative Domain ). The challenge from my point of view was
> and still is how to treat non-transitive attributes as transitive across
> the set of AS domains that “belong” to the same administrative domain. An
> example of this is the application of Local-Pref across a set of disparate
> As domains that a customers VPN spans.*
>
>
>
> *We are tackling a similar problem when spanning AS domains that are
> reflective of differing services.. i.e  a customer VPN spans EVPN and 2547
> signaling domains.*
>
>
>
> *https://tools.ietf.org/html/draft-uttaro-idr-oad-01
> <https://tools.ietf.org/html/draft-uttaro-idr-oad-01> *
>
>
>
> *https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02
> <https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02> *
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* Idr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, April 08, 2020 10:41 AM
> *To:* Jakob Heitz (jheitz) 
> *Cc:* idr@ietf. org 
> *Subject:* [Idr] XXCs
>
>
>
> Hey Jakob,
>
>
>
> So just an idea - if we are to redefine transitivity for XXC why don't we
> forget about all of this ASN reservations and simply instead of two
> transitive bits define three.
>
>
>
> Make 3rd bit to mean transitive only under set of ASes under same
> administrative control ?
>
>
>
> You still need a knob to know which ASNs are to be treated as same
> administration. And with that no change to community syntax  is needed at
> all - LOCAL_ASN:NUMBER
>
>
>
> Done !
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Gyan,

As topic 1 - Extended community which is used for filtering incoming
updates can be configured under BGP AF - there is nothing in the protocol
which mandates that such RTs need to be configured under VRF section.

As of topic 2 - This is huge misconception by many people who think that
SAFI 128 requires MPLS transport. So let me clearly state that SAFI 128
application can happily run for many years now over pure IP transport. VPN
labels and transport paradigm are completely separate. Hint: RFC7510 or
RFC4023. Moreover - let me also state that MPLS transport does not bring
any benefits other then few bits savings in the packet header as compared
with say IPv4 transport. Contrary it costs a lot of complexity in the
control plane and forwarding planes of the network elements.

Thx,
R.



On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra  wrote:

>
> Robert  & Linda
>
> Sorry to inject myself into this thread.
>
> You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control
> plane service layer overlay from PE to RR. Agreed.  By default all PEs
> including the SDWAN PE have RT Filtering enabled by default and only import
> the RT into the VRF at the control plane level if the VRF is configured
> with RT advertised by the RR is being imported by the PE, if not the SAFI
> 128 prefixes are dropped.  So I understand that the BGP updates is a
> control plane function, but how would the routes get imported by the PE if
> the VRF is not defined on the PE.  RFC 4684 RTC capability allows only the
> RTs imported on the PE to be advertised by the RR to reduced the SAFI 128
> route advertised by the RR that would result in being filtered on the PE.
>
> So how would that work using SAFI 128 RT to provide the network slicing
> for SDWAN without VRF configured.
>
> Also you mentioned that SAFI 128 L3 vpn services overlay can run over any
> underlay and that does not have to be MPLS based.  I know SAFI 128 works
> with SR-MPLS but there you are reusing the MPLS data plane.  With SRv6 due
> to PM draft signaling by egress PE for end.dx instantiation, so there is
> not any service label necessary as is with MPLS and thus SAFI 128 works
> with SRv6.
>
> How would SAFI 128 work with IP underlay used with SDWAN?
>
> Even with  inter-as option b c ab, with BGP LU you do have topmost label
> which is via BGP labeled unicast.  For inter as options if SAFI128 would
> work w/o BGP LU you could just run SAFI 128 over IP.  I have never tried
> but I think the control plane would come up but the data plane would be
> broken.
>
> Kind regards
>
> Gyan
>
> On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar 
> wrote:
>
>> Robert,
>>
>>
>>
>> Want to confirm the following two points with you. Do I interpret your
>> words correctly?
>>
>>
>>
>>- If a CPE supports traditional VPN with multiple VRFs, and supports
>>multiple SDWAN instances, the traditional VRF configuration is still same
>>which are carried by BGP Route Target Extended community.
>>- For the SDWAN Instances supported by the same CPE, we can use
>>Extended Community with a different name (say SDWAN Target ID). When the
>>SDWAN Target ID is used, the SAFI 128 can be used for routes for the SDWAN
>>instance,  with the exception that the label in the NLRI is not the MPLS
>>label carried by the data packets .
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Linda Dunbar
>>
>> *From:* Robert Raszuk 
>> *Sent:* Tuesday, March 24, 2020 3:32 AM
>> *To:* Linda Dunbar 
>> *Cc:* Huaimo Chen ; i...@ietf.org;
>> bess@ietf.org
>> *Subject:* Re: [Idr] Seeking feedback of
>> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance
>> ID in the NLRI
>>
>>
>>
>> Hi Linda,
>>
>>
>>
>> Nope you do not need VRFs. RT construct works at the control plane level..
>> VRF may be useful for traffic separation purposes on multitenant CPEs or if
>> you would like to relax requirements for unique IP across SDWAN sites - but
>> not a must otherwise.
>>
>>
>>
>> My main point was  that BGP SAFI 128 gives you for free transport for
>> multiple routing contexts so why not leverage it as is?
>>
>>
>>
>> Moreover you may suddenly also discover that RTC (RFC4684) is your
>> SDWAN friend too.
>>
>>
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
>> wrote:
>>
>> Robert,
>>
>>
>>
>> Thank you very much for the feedback.
>>
>>
>

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Linda,

Nope you do not need VRFs. RT construct works at the control plane level.
VRF may be useful for traffic separation purposes on multitenant CPEs or if
you would like to relax requirements for unique IP across SDWAN sites - but
not a must otherwise.

My main point was  that BGP SAFI 128 gives you for free transport for
multiple routing contexts so why not leverage it as is?

Moreover you may suddenly also discover that RTC (RFC4684) is your
SDWAN friend too.

Many thx,
R.




On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the feedback.
>
>
>
> If using your suggested Route Target approach to represent the SDWAN
> Instance ID, does it mean that a SDWAN Edge has to use the same approach to
> configure the VRF for SDWAN instances?
>
> If the edge node supports both traditional VPN and SDWAN, will it cause
> confusion for RT to represent both?
>
>
>
> RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is
> encoded in the MP_REACH_NLRI Path Attribute.
>
>
>
> What do you mean by saying “different name to Route target(s) carried in
> the SAFI 128”?
>
> Do you mean having a different name (say SDWAN_Target) in
> Extended_Communities Path Attribute, and have MP_REACH_NLRI Path Attribute
> including the SAFI 128?
>
>
>
> SDWAN Instance ID is for the control Plane, not to be carried by the data
> packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is
> to be carried by the data packets. But SDWAN Instance ID is not carried by
> the Data Packets. Is it correct?
>
>
>
> Thank you.
>
> Linda
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, March 23, 2020 2:28 PM
> *To:* Linda Dunbar 
> *Cc:* Huaimo Chen ; i...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi
> using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
>
>
>
> Hi Linda,
>
>
>
> I think you are mixing data plane and control plane.
>
>
>
> In SDWAN data plane is of no issue as you are interconnecting sites in a
> given VPN over mesh of secure tunnels.
>
>
>
> You are asking how to keep control plane separate between VPN instances.
> This is precisely what RFC4364 does already and RT import/export is used to
> indicate the instance which given set of reachability belongs. Why to
> reinvent the wheel and do something new just for the heck of it :) ?
>
>
>
> To be original you can at best invent a different name to Route target(s)
> carried in the SAFI 128 but let's keep the mechanism the same. That would
> be my suggestion.
>
>
>
> Kind regards,
>
> R.
>
>
>
> PS. While this is obvious for some many folks are still confused. RFC4364
> does not need to run over MPLS data plane. It can run over IPSec or over
> DTLS or over UDP/IP just fine.
>
>
>
> On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
> wrote:
>
> IDR experts:
>
>
>
> SDWAN is an overlay network arching over multiple types of networks. A
> SDWAN edge node may need to map client traffic to different SDWAN network
> instances (or segmentations).
>
> It might not be feasible to use the AS number in the BGP message to
> differentiate the SDWAN network instances as multiple SDWAN instances may
> share the same AS number.
>
>
>
> We would like to hear feedback from IDR group on using similar method as
>  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance
> ID to  prefixes.
>
>
>
> When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI
> [RFC8277] as:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length | Label |Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Figure 2: NLRI with One Label
>
>
>
> We would like to  propose the SDWAN Instance ID being encoded in the Label
> field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a
given VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances.
This is precisely what RFC4364 does already and RT import/export is used to
indicate the instance which given set of reachability belongs. Why to
reinvent the wheel and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s)
carried in the SAFI 128 but let's keep the mechanism the same. That would
be my suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364
does not need to run over MPLS data plane. It can run over IPSec or over
DTLS or over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
wrote:

> IDR experts:
>
>
>
> SDWAN is an overlay network arching over multiple types of networks. A
> SDWAN edge node may need to map client traffic to different SDWAN network
> instances (or segmentations).
>
> It might not be feasible to use the AS number in the BGP message to
> differentiate the SDWAN network instances as multiple SDWAN instances may
> share the same AS number.
>
>
>
> We would like to hear feedback from IDR group on using similar method as
>  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance
> ID to  prefixes.
>
>
>
> When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI
> [RFC8277] as:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length | Label |Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Figure 2: NLRI with One Label
>
>
>
> We would like to  propose the SDWAN Instance ID being encoded in the Label
> field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length |  SDWAN Instance ID (Label)|Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> NLRI with SDWAN Instance ID.
>
>
>
> Greatly appreciate any comments or other suggestions..
>
>
>
> Thank you,
>
> Linda Dunbar
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Monday, March 23, 2020 9:14 AM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that using another SAFI is a possible solution.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Linda Dunbar 
> *Sent:* Friday, March 20, 2020 12:54 AM
> *To:* Huaimo Chen ; i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* RE: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Huaimo,
>
>
>
> Thank you very much for the suggestion.
>
> Do you mean using the similar approach as VPN Label carried by NLRI Path
> Attribute [RFC8277] for SDWAN Segmentation Identifier?
>
> If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to
> avoid confusion, right?
>
>
>
> Linda
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Thursday, March 19, 2020 6:45 PM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that a label may be used as an "Identifier" to differentiate
> SD-WAN Segmentation.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Idr  on behalf of Linda Dunbar <
> linda.dun...@futurewei.com>
> *Sent:* Thursday, March 19, 2020 1:22 PM
> *To:* i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> BGP Experts,
>
>
>
> Do you 

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[Robert Raszuk]

Hi Gyan,

You are touching subject close to me so let me share my perspective on your
doubts below ;)

>  maybe some advantages of elimination of L2 to the host

Not some but huge !

>  BGP multipath provides flow based uneven load balancing

First Contrail/Tungsten does not use BGP to the hypervisor but XMPP. But
this is opaque to your concern.

Load balancing and hashing construction is your choice, BGP or XMPP only
deliver you next hops .. how you spread traffic to them is 100% up to your
choice. That is the same on hypervisor or on any decent router. LAGs also
build hash in the way you configure them to do so.

>  hypervisor managed by server admins

In any decent network or for that matter even in my lab this is all 100%
automated. You run one template and execute it. Ansible works pretty well,
but there are other choices too.

Many thx,
R.


On Tue, Mar 3, 2020 at 1:00 AM Gyan Mishra  wrote:

>
> Thanks Robert for the quick response
>
> Just thinking out loud -  I can see there maybe some advantages of
> elimination of L2 to the host but the one major disadvantage is that BGP
> multipath provides flow based uneven load balancing so not as desirable
> from that standpoint compare to L3 MLAG bundle XOR Src/Dest/Port hash.
>
> Other big down side is most enterprises have the hypervisor managed by
> server admins but if you run BGP now that ends up shifting to network.
> More complicated.
>
> Kind regards
>
> Gyan
>
> On Mon, Mar 2, 2020 at 6:39 PM Robert Raszuk  wrote:
>
>> Hi Gyan,
>>
>> Similar architecture has been invented and shipped by Contrail team. Now
>> that project after they got acquired by Juniper has been renamed to
>> Tungsten Fabric https://tungsten.io/ while Juniper continued to keep the
>> original project's name and commercial flavor of it. No guarantees of any
>> product quality at this point.
>>
>> Btw ,,, no need for VXLAN nor BGP to the host. The proposed above
>> alternative were well thought out and turned to work ways far more
>> efficient and practical if you zoom into details.
>>
>> Best,
>> Robert.
>>
>>
>> On Tue, Mar 3, 2020 at 12:26 AM Gyan Mishra 
>> wrote:
>>
>>>
>>> Dear BESS WG
>>>
>>> Is anyone aware of any IETF BGP development in the Data Center arena to
>>> extend BGP VXLAN EVPN to a blade server Hypervisor making the Hypervisor
>>> part of the  vxlan fabric.  This could eliminate use of MLAG on the leaf
>>> switches and eliminate L2 completely from the vxlan fabric thereby
>>> maximizing  stability.
>>>
>>> Kind regards,
>>>
>>> Gyan
>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mis...@verizon.com
>>>
>>>
>>>
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mis...@verizon.com
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[Robert Raszuk]

Hi Gyan,

Similar architecture has been invented and shipped by Contrail team. Now
that project after they got acquired by Juniper has been renamed to
Tungsten Fabric https://tungsten.io/ while Juniper continued to keep the
original project's name and commercial flavor of it. No guarantees of any
product quality at this point.

Btw ,,, no need for VXLAN nor BGP to the host. The proposed above
alternative were well thought out and turned to work ways far more
efficient and practical if you zoom into details.

Best,
Robert.


On Tue, Mar 3, 2020 at 12:26 AM Gyan Mishra  wrote:

>
> Dear BESS WG
>
> Is anyone aware of any IETF BGP development in the Data Center arena to
> extend BGP VXLAN EVPN to a blade server Hypervisor making the Hypervisor
> part of the  vxlan fabric.  This could eliminate use of MLAG on the leaf
> switches and eliminate L2 completely from the vxlan fabric thereby
> maximizing  stability.
>
> Kind regards,
>
> Gyan
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mis...@verizon.com
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-zzhang-bess-bgp-multicast-controller

[Robert Raszuk]

Support as co-author.



Not aware of undisclosed IPR relevant to this draft.



Thanks!

Robert

On Mon, Jan 6, 2020 at 3:13 PM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for and
> draft-zzhang-bess-bgp-multicast-controller-02 [1] ..
>
> For information, it’s companion document
> (draft-zzhang-bess-bgp-multicast-03) is also polled for WG adoption in a
> separate email.
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on *** 20th January 2020 ***
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast-controller/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8277

[Robert Raszuk]

/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only
local significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is
quite surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
wrote:

>
> Regarding RFC 8277 Section 3.2.2
> 3.2.2.  When the Next Hop Field Is Changed
>
>If the Network Address of Next Hop field is changed before a SAFI-4
>or SAFI-128 route is propagated, the Label field(s) of the propagated
>route MUST contain the label(s) that is (are) bound to the prefix at
>the new next hop.
>
>
> "the Label field(s) of the propagated route MUST contain the label(s) that
> is (are) bound to the prefix at the new next hop."
>
> This specification should apply when the next hop field of the route is
> changed by any means such as route map, route policies, or next-hop-self
> and propagated?
>
> I've experienced differing behaviors between platforms as to whether or
> not a the label is changed when the next hop field is changed with a route
> map or route policy.
>
> For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32
> with label 1 from R1.  R2 changes the next hop field with an outbound route
> policy but doesn't replace the label before propagating the route to R3.
> R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the LSP.
>
> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>
>
> However on other platforms inter-as option b R2 receives VPNv4 route
> 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with an
> outbound route policy and does replace the label before propagating the
> route to R3.  R3 receives VPNv4 route 1.1.1.1/32 and new label 2.
>
> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>
>
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi Acee,

There is no single vendor mentioned. There is no name of the reporter
mentioned. This is not an implementation report.

This draft sole reasoning is based on the implementations. I am looking for
formal implementation report - just like we always do in idr:

https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Example:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

Thx,
R.


On Tue, Dec 3, 2019 at 5:24 PM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Tuesday, December 3, 2019 at 8:25 AM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi,
>
>
>
> I am not that naive to think that you can do something else here ;)
>
>
>
> But can you at least send a pointer to formal implementation report before
> proceeding ?
>
>
>
> Here are the slides presented at the Tuesday afternoon BESS WG sessions.
> The results of the implementation survey are included.
>
>
>
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-bess-sessa-draft-litkowski-bess-vpnv4-ipv6-nh-handling-00-00
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thx a lot,
>
> R.
>
>
>
> On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
> My point is that your proposal to save the 8 bytes of RD can be
> independent of correcting RFC 5449. It is pretty much a no-brainer that
> revising the specification to match the de facto standard of all extant
> implementations is preferable to a non-trivial upgrade and migration.
>
>
>
> Anyway, I don’t wish to engage in a protracted debate and I don’t believe
> the WG wishes to delay publication of this draft. Your lone objection can
> be noted in the shepherds report.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Robert Raszuk 
> *Date: *Monday, December 2, 2019 at 6:37 PM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi Acee,
>
>
>
> Please observe that this draft defines encoding for SAFI 129 with IPv6 as
> next hop.
>
>
>
> If we are prepend it with zero pls do not forget to also submit the errata
> to RFC 6514 which says
>
> clearly in section 9.2.3.2 that next hop *field* must be set to a routable
> IP address. Not part of the
>
> Next Hop field but the entire *field*.
>
>
>
>When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
>
>the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
>
>address of the ASBR.
>
>
>
> And the above is just the tip of the iceberg :)
>
>
>
> Bottom line is that instead of publishing the spec which in backwards 
> compatible fashion allows
>
> gradually to fix the implementation errors of the past it is just blessing 
> them. And we all agree
>
> that pushing to each MP_REACH NH field 64 zeros is completely unnecessary.. 
> Not a good thing
>
> in my measures.
>
>
>
> Best,
>
> R.
>
>
>
> PS. And what happens if those 8 octets is not zeros but zero and ones ? 
> Should it be accepted and
>
> ignored or is this an invalid attribute ?
>
>
>
>
>
>
>
> On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:
>
> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org&

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi,

I am not that naive to think that you can do something else here ;)

But can you at least send a pointer to formal implementation report before
proceeding ?

Thx a lot,
R.

On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee)  wrote:

> Hi Robert,
>
> My point is that your proposal to save the 8 bytes of RD can be
> independent of correcting RFC 5449. It is pretty much a no-brainer that
> revising the specification to match the de facto standard of all extant
> implementations is preferable to a non-trivial upgrade and migration.
>
>
>
> Anyway, I don’t wish to engage in a protracted debate and I don’t believe
> the WG wishes to delay publication of this draft. Your lone objection can
> be noted in the shepherds report.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Robert Raszuk 
> *Date: *Monday, December 2, 2019 at 6:37 PM
> *To: *Acee Lindem 
> *Cc: *"slitkows.i...@gmail.com" , "Bocci,
> Matthew (Nokia - GB)" , "bess-cha...@ietf.org" <
> bess-cha...@ietf.org>, "bess@ietf.org" 
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Hi Acee,
>
>
>
> Please observe that this draft defines encoding for SAFI 129 with IPv6 as
> next hop.
>
>
>
> If we are prepend it with zero pls do not forget to also submit the errata
> to RFC 6514 which says
>
> clearly in section 9.2.3.2 that next hop *field* must be set to a routable
> IP address. Not part of the
>
> Next Hop field but the entire *field*.
>
>
>
>When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
>
>the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
>
>address of the ASBR.
>
>
>
> And the above is just the tip of the iceberg :)
>
>
>
> Bottom line is that instead of publishing the spec which in backwards 
> compatible fashion allows
>
> gradually to fix the implementation errors of the past it is just blessing 
> them. And we all agree
>
> that pushing to each MP_REACH NH field 64 zeros is completely unnecessary.. 
> Not a good thing
>
> in my measures.
>
>
>
> Best,
>
> R.
>
>
>
> PS. And what happens if those 8 octets is not zeros but zero and ones ? 
> Should it be accepted and
>
> ignored or is this an invalid attribute ?
>
>
>
>
>
>
>
> On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:
>
> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org" , "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Stephane,
>
>
>
> Adding ability to recognize the length of the next hop to any code is
> purely incremental thing. When vendors were asked I do not even recall if
> there was a question if given implementation can infer next hop format from
> length or not - and that is the key problem/point here.
>
>
>
> Just asking if you are prepending zeros or not to NH in some SAFIs and
> stating that if so you do revise 5549 to reflect that is not what we should
> be doing.
>
>
>
> The main reason is that as SAFIs are being defined every now and then and
> there is still no clear document if next hop should match NLRI type or not.
> Moreover 4364 is still being developed in few vendors. Sure they want to be
> backwards compatible too, but with that let's also give them a chance to do
> the right thing vs just follow legacy.
>
>
>
> So yes if you are opening that box my suggestion is to define an
> additional capability indicating if receiver can process next hop without
> any additional nonsense zero padding. All it takes is one paragraph/section
> and one IANA codepoint.
>
>
>
> Stating that this should be new sepa

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Hi Acee,

Please observe that this draft defines encoding for SAFI 129 with IPv6 as
next hop.

If we are prepend it with zero pls do not forget to also submit the errata
to RFC 6514 which says
clearly in section 9.2.3.2 that next hop *field* must be set to a routable
IP address. Not part of the
Next Hop field but the entire *field*.

   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
   address of the ASBR.


And the above is just the tip of the iceberg :)


Bottom line is that instead of publishing the spec which in backwards
compatible fashion allows

gradually to fix the implementation errors of the past it is just
blessing them. And we all agree

that pushing to each MP_REACH NH field 64 zeros is completely
unnecessary. Not a good thing

in my measures.


Best,

R.

PS. And what happens if those 8 octets is not zeros but zero and ones
? Should it be accepted and
ignored or is this an invalid attribute ?



On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee)  wrote:

> Robert,
>
>
>
> What you’re suggesting doesn’t really solve the problem that all the
> currently deployed routers that do not follow RFC 5549. No known
> implementations follow RFC 5549. Were you on the meetecho when this was
> presented in the BESS meeting at IETF 106? There was clear consensus in the
> meeting.
>
>
>
> Anyway,  you can put your ideas in a new draft and let them stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, November 28, 2019 at 11:58 AM
> *To: *"slitkows.i...@gmail.com" 
> *Cc: *"Bocci, Matthew (Nokia - GB)" , "
> bess-cha...@ietf.org" , "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> Stephane,
>
>
>
> Adding ability to recognize the length of the next hop to any code is
> purely incremental thing. When vendors were asked I do not even recall if
> there was a question if given implementation can infer next hop format from
> length or not - and that is the key problem/point here.
>
>
>
> Just asking if you are prepending zeros or not to NH in some SAFIs and
> stating that if so you do revise 5549 to reflect that is not what we should
> be doing.
>
>
>
> The main reason is that as SAFIs are being defined every now and then and
> there is still no clear document if next hop should match NLRI type or not.
> Moreover 4364 is still being developed in few vendors. Sure they want to be
> backwards compatible too, but with that let's also give them a chance to do
> the right thing vs just follow legacy.
>
>
>
> So yes if you are opening that box my suggestion is to define an
> additional capability indicating if receiver can process next hop without
> any additional nonsense zero padding. All it takes is one paragraph/section
> and one IANA codepoint.
>
>
>
> Stating that this should be new separate document again updating 5549 and
> now 5549revised is really not the best option.
>
>
>
> Best,
>
> Robert
>
>
>
> On Thu, Nov 28, 2019 at 5:40 PM  wrote:
>
> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk 
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB)  >
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> *I do not support this draft in the current form. *
>
>
>
> This document instead of improving the original specification makes it
> actually worse.
>
> [SLI]
>
>
>
> Point 1 -
>
>
>
> Original RFC sec. 6.2:
>
>
>o  Network Address of Next Hop = IPv6 address of Next Hop
>
>
>
> Proposed text:
>
>
>
>o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
>
> RD is set to zero
>
>
>
>
>
> As it has been explained when you negotiate in capability AFI2 as next hop
> it is just 16 octets - not 24.
>
> [SLI] AFI2 means that the nexthop is encoded with a format compliant with
> an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is
> still AFI2.
>
>
>
> Next hop never has an RD.
>
> [SLI] We have already discussed about that. RD doesn’t make any sense for
> a

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Stephane,

Adding ability to recognize the length of the next hop to any code is
purely incremental thing. When vendors were asked I do not even recall if
there was a question if given implementation can infer next hop format from
length or not - and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and
stating that if so you do revise 5549 to reflect that is not what we should
be doing.

The main reason is that as SAFIs are being defined every now and then and
there is still no clear document if next hop should match NLRI type or not.
Moreover 4364 is still being developed in few vendors. Sure they want to be
backwards compatible too, but with that let's also give them a chance to do
the right thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional
capability indicating if receiver can process next hop without any
additional nonsense zero padding. All it takes is one paragraph/section and
one IANA codepoint.

Stating that this should be new separate document again updating 5549 and
now 5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM  wrote:

> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk 
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB) 
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> *I do not support this draft in the current form. *
>
>
>
> This document instead of improving the original specification makes it
> actually worse.
>
> [SLI]
>
>
>
> Point 1 -
>
>
>
> Original RFC sec. 6.2:
>
>
>o  Network Address of Next Hop = IPv6 address of Next Hop
>
>
>
> Proposed text:
>
>
>
>
>o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
>
> RD is set to zero
>
>
>
>
>
> As it has been explained when you negotiate in capability AFI2 as next hop
> it is just 16 octets - not 24.
>
> [SLI] AFI2 means that the nexthop is encoded with a format compliant with
> an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is
> still AFI2.
>
>
>
> Next hop never has an RD.
>
> [SLI] We have already discussed about that. RD doesn’t make any sense for
> a nexthop address. No one disagrees on that point. However our legacy
> 2547bis introduced a nexthop encoded as a VPN-IP address, and all VPN
> unicast SAFIs are following this. As RD does not make sense, zeroes are
> just added to fit the size of the address format. In reality, it is just an
> IP address with 0es padded before. Of course,  it would have been cleaner
> to use only a regular IP address instead of a VPN-IP address but again
> that’s our legacy.
>
>
>
> The fact that some implementations are matching length of NLRI with length
> of next hop no where should be made equal that next hop has 8 octet dummy
> Route Distinguisher.
>
> [SLI] Again this is coming from legacy.
>
>
>
>
>
> If revision is to be made would be to explicitly negotiate capability to
> infer next hop encoding from the length.
>
> [SLI] Are you talking about a new capability or the existing ENH cap ? ENH
> tells you what is the NH AFI, so the only length check required is for the
> case of one or two IPv6 addresses. A new cap means a new solution, and
> that’s not the goal here.
>
>
>
>
>
> Point 2 -
>
>
>
> Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding
> is lightly stating suboptimal.
>
>
>
> Conclusion:
>
>
>
> As we have discussed on and off line if revision is to be made let's make
> it both backwards compatible, Let's make it applicable to both IPv4 and
> IPv6 next hop addresses and let's allow explicit capability where
> implementations could indicate that it can recognize next hop value from
> its length. After all we are talking about just 4 discrete possible values
> here.
>
> [SLI] The goal is not to create something new here, but just to reflect
> how RFC5549 has been implemented for the SAFI 128/129 cases. The goal is
> also to minimize running code changes too (and even avoid !). We have to
> deal with what has been shipped and deployed by vendors today. We can still
> create something completely new, with a new cap and new procedures, but I
> think this is orthogonal to “aligning RFC5549 with implementations” as
> RFC5549 is there anyway and we can’t blindly forget it due to the codes
> that are available.
>
>
>
>
>
>
>
> Cheers,
>
> Robert.
>
>
>
>
>
>
>
>
>
>

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

*I do not support this draft in the current form. *

This document instead of improving the original specification makes it
actually worse.

Point 1 -

Original RFC sec. 6.2:

o Network Address of Next Hop = IPv6 address of Next Hop

Proposed text:


o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
RD is set to zero

As it has been explained when you negotiate in capability AFI2 as next hop
it is just 16 octets - not 24. Next hop never has an RD. The fact that some
implementations are matching length of NLRI with length of next hop no
where should be made equal that next hop has 8 octet dummy Route
Distinguisher.

If revision is to be made would be to explicitly negotiate capability to
infer next hop encoding from the length.

Point 2 -

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding
is lightly stating suboptimal.

Conclusion:

As we have discussed on and off line if revision is to be made let's make
it both backwards compatible, Let's make it applicable to both IPv4 and
IPv6 next hop addresses and let's allow explicit capability where
implementations could indicate that it can recognize next hop value from
its length. After all we are talking about just 4 discrete possible values
here.

Cheers,
Robert.









On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-litkowski-bess-rfc5549revision-00 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Wednesday 11th December 2019.
>
>
>
> Regards,
>
> Matthew
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

[Robert Raszuk]

> it is tremendous amount of work.

Well I am afraid this is entering implementation space and not subject to
any further debate on or off the list. Only note that IPSec is not the only
payload encryption option at your disposal for quality SDWANs.

On Tue, Nov 5, 2019 at 11:07 PM Linda Dunbar  wrote:

> Robert,
>
>
>
> It is not the FIB size, but the number of IPsec SA maintenance required at
> each edge node that makes it difficult to scale more than 100 nodes.
>
> Each IPsec SA requires periodical key refreshment. For one node
> maintaining X number of IPsec SA, it is tremendous amount of work.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, November 05, 2019 3:15 PM
> *To:* Linda Dunbar 
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Linda,
>
>
>
> The key message here is that in properly designed SDWAN your limit is
> capped by volume of data traffic required to be encrypted and supported by
> your platform. Number of overlay adjacencies does not matter.
>
>
>
> It does not matter since the size of your FIB has orders of magnitude more
> capacity then any single SDWAN number of endpoints.
>
>
>
> Best,
>
> R,
>
>
>
> On Tue, Nov 5, 2019 at 9:20 PM Linda Dunbar  wrote:
>
> Robert,
>
>
>
> You said “It has been deployed and is fully operating with no concern of
> scalability for number of years at least from one vendor I am aware of.”
>
>
>
> How many nodes of this deployment?
>
>
>
> As you described: just two nodes might need 18 IPsec tunnels. How about
> 100 node SDWAN network? 100*99 * 18?
>
>
>
> “So number of overlay pipes to be created in corresponding SDWAN data
> planes is 9 in each direction just over those *two* end points. 18 if you
> consider bidirectional traffic”
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, November 04, 2019 6:54 PM
> *To:* Linda Dunbar 
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Hi Linda,
>
>
>
> > Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec
>
> > Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
> to many.
>
>
>
> Please observe that any to any encapsulated paths setup in good SDWAN is
> day one requirement. And that is not only any src/dst to any src/dst. It is
> actually from any source interface over any available underlay to any
> available remote interface of the destination.
>
>
>
> Imagine if you have two end points each with three interfaces to the
> underlay. So number of overlay pipes to be created in corresponding
> SDWAN data planes is 9 in each direction just over those *two* end points..
> 18 if you consider bidirectional traffic.
>
>
>
> Good SDWAN can build such state and not only that .. it can also run in
> continued fashion SLA probes over all possible paths between given src and
> destination. When data is sent over selected per application path it is
> then encrypted. It can even do much more ... it can perform
> SDWAN-TE treating some endpoints as transits :).
>
>
>
> It has been deployed and is fully operating with no concern of scalability
> for number of years at least from one vendor I am aware of. So I question
> your observation and do believe that adding vrf based routing over well
> designed and correctly written SDWAN is of any scalability concern. As a
> matter of fact the implementation I am familiar with also has built in
> concept of VRFs too.
>
>
>
> No it is not trivial - but clearly possible.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar 
> wrote:
>
> In MEF SD-WAN Service Specification WG, there has been a lot of discussion
> on Application Flow Based Segmentation.
>
> Application Flow based Segmentation refers to separating traffic based on
> business and security needs, e.g. having different topology for different
> traffic types or users/apps.
>
> For example, retail business requires traffic from payment applications in
> all branches only go to the Payment Gateway in its HQ Data Centers, whereas
> other applications can be multi-point (in Cloud DC too).
>
> Segmentation is a feature that can be provided or enabled for a single
> SDWAN service (or domain). Each Segment can have its own policy and
> topology.
>
> In the figure below, the traffic from the Payment application (Red Dotted
> line) is along t

Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

[Robert Raszuk]

Linda,

The key message here is that in properly designed SDWAN your limit is
capped by volume of data traffic required to be encrypted and supported by
your platform. Number of overlay adjacencies does not matter.

It does not matter since the size of your FIB has orders of magnitude more
capacity then any single SDWAN number of endpoints.

Best,
R,

On Tue, Nov 5, 2019 at 9:20 PM Linda Dunbar  wrote:

> Robert,
>
>
>
> You said “It has been deployed and is fully operating with no concern of
> scalability for number of years at least from one vendor I am aware of.”
>
>
>
> How many nodes of this deployment?
>
>
>
> As you described: just two nodes might need 18 IPsec tunnels. How about
> 100 node SDWAN network? 100*99 * 18?
>
>
>
> “So number of overlay pipes to be created in corresponding SDWAN data
> planes is 9 in each direction just over those *two* end points. 18 if you
> consider bidirectional traffic”
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, November 04, 2019 6:54 PM
> *To:* Linda Dunbar 
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Hi Linda,
>
>
>
> > Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec
>
> > Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
> to many.
>
>
>
> Please observe that any to any encapsulated paths setup in good SDWAN is
> day one requirement. And that is not only any src/dst to any src/dst. It is
> actually from any source interface over any available underlay to any
> available remote interface of the destination.
>
>
>
> Imagine if you have two end points each with three interfaces to the
> underlay. So number of overlay pipes to be created in corresponding
> SDWAN data planes is 9 in each direction just over those *two* end points..
> 18 if you consider bidirectional traffic.
>
>
>
> Good SDWAN can build such state and not only that .. it can also run in
> continued fashion SLA probes over all possible paths between given src and
> destination. When data is sent over selected per application path it is
> then encrypted. It can even do much more ... it can perform
> SDWAN-TE treating some endpoints as transits :).
>
>
>
> It has been deployed and is fully operating with no concern of scalability
> for number of years at least from one vendor I am aware of. So I question
> your observation and do believe that adding vrf based routing over well
> designed and correctly written SDWAN is of any scalability concern. As a
> matter of fact the implementation I am familiar with also has built in
> concept of VRFs too.
>
>
>
> No it is not trivial - but clearly possible.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar 
> wrote:
>
> In MEF SD-WAN Service Specification WG, there has been a lot of discussion
> on Application Flow Based Segmentation.
>
> Application Flow based Segmentation refers to separating traffic based on
> business and security needs, e.g. having different topology for different
> traffic types or users/apps.
>
> For example, retail business requires traffic from payment applications in
> all branches only go to the Payment Gateway in its HQ Data Centers, whereas
> other applications can be multi-point (in Cloud DC too).
>
> Segmentation is a feature that can be provided or enabled for a single
> SDWAN service (or domain). Each Segment can have its own policy and
> topology.
>
> In the figure below, the traffic from the Payment application (Red Dotted
> line) is along the Tree topology, whereas other traffic can be multipoint
> to multi point topology as in VRF.
>
>
>
>
>
>
>
> Segmentation is analogous to VLAN (in L2 network) and VRF (in L3 network)..
> But unlike VRF where all the intermediate nodes can forward per VRF, in
> SDWAN Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec Point to Point tunnel, there would be N*(N-1) tunnels, which is
> too many to many.
>
>
>
> Does anyone know an existing protocol that can handle the above scenario
> described in
> https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F=02%7C01%7Cldunbar%40futurewei.com%7C3bf3d3284c07ad6908d7618aa34a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085120416218921=deTxi%2FNkX678x8qEX4hCipAcf%2ByosvtUu%2Fu2iA5aFRA%3D=0>
>
>
>
>
>
> Thank you very much.
>

Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

[Robert Raszuk]

Hi Linda,

> Overlay, the multipoint to multipoint WAN is an overlay network. If using
IPsec
> Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
to many.

Please observe that any to any encapsulated paths setup in good SDWAN is
day one requirement. And that is not only any src/dst to any src/dst. It is
actually from any source interface over any available underlay to any
available remote interface of the destination.

Imagine if you have two end points each with three interfaces to the
underlay. So number of overlay pipes to be created in corresponding
SDWAN data planes is 9 in each direction just over those *two* end points.
18 if you consider bidirectional traffic.

Good SDWAN can build such state and not only that .. it can also run in
continued fashion SLA probes over all possible paths between given src and
destination. When data is sent over selected per application path it is
then encrypted. It can even do much more ... it can perform
SDWAN-TE treating some endpoints as transits :).

It has been deployed and is fully operating with no concern of scalability
for number of years at least from one vendor I am aware of. So I question
your observation and do believe that adding vrf based routing over well
designed and correctly written SDWAN is of any scalability concern. As a
matter of fact the implementation I am familiar with also has built in
concept of VRFs too.

No it is not trivial - but clearly possible.

Best,
Robert.


On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar  wrote:

> In MEF SD-WAN Service Specification WG, there has been a lot of discussion
> on Application Flow Based Segmentation.
> Application Flow based Segmentation refers to separating traffic based on
> business and security needs, e.g. having different topology for different
> traffic types or users/apps.
> For example, retail business requires traffic from payment applications in
> all branches only go to the Payment Gateway in its HQ Data Centers, whereas
> other applications can be multi-point (in Cloud DC too).
> Segmentation is a feature that can be provided or enabled for a single
> SDWAN service (or domain). Each Segment can have its own policy and
> topology.
> In the figure below, the traffic from the Payment application (Red Dotted
> line) is along the Tree topology, whereas other traffic can be multipoint
> to multi point topology as in VRF.
>
>
>
> Segmentation is analogous to VLAN (in L2 network) and VRF (in L3 network).
> But unlike VRF where all the intermediate nodes can forward per VRF, in
> SDWAN Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec Point to Point tunnel, there would be N*(N-1) tunnels, which is
> too many to many.
>
> Does anyone know an existing protocol that can handle the above scenario
> described in
> *https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/*
> 
>
>
> Thank you very much.
>
> Linda Dunbar
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Hi Matthew, Stéphane,

I’m not aware of any non-disclosed IPR.

KInd regards,
Robert.

On Fri, Sep 27, 2019 at 1:00 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Support (as co-author).

Also I am not aware of any undisclosed IPR related to this document.

Thx,
R.

On Fri, Sep 27, 2019 at 1:00 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Hello Gyan,

I have read your comment few times. but can't parse it.

Is this a question ? A concern ? Just comment ?

You say:

"Is that true and if so that is a major design concern for migration of
customers to a SRv6 core."

But what is that ? I am very happy to answer any questions you may have in
honest way, but just need to understand what the question really is.

Thx,
R.

On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra  wrote:

>
> Hi Robert
>
> In-line question
>
> Sent from my iPhone
>
> On Oct 3, 2019, at 11:01 AM, Robert Raszuk  wrote:
>
> Hi Linda,
>
> Nope. Nodes except egress have any reason to look at VPN label. That label
> has only local significance on egress.
>
> Thx,
> R.
>
>
> Robert
>
> From an operator perspective ease of implementation and migration is
> critical to deployment.
>
> So just as with SR-MPLS where you can prefer SR over mpls and it’s a swap
> of the “topmost label” in the label stack and all VPN services label at the
> bottom of the stack remain unchanged.  Drawing an analogy to SRv6 scenario
> that would it be exactly the same it sounds like that L3 VPN vpn label
> remains intact for vpnv4 vpnv6 scenario and IP native native IPv4 / IPv6
> encapsulation IP/MPLS remains the same no change and it’s just the
> “topmost” label gets swapped out from either legacy mpls LDP/TE to either
> SR-MPLS or now SRv6 topmost label. The services bottom label are only
> imposed by ingress PE as with legacy mpls and per SRv6 End SID programming
> is either PSP or USP popped similar to legacy mpls PHP UHP and VPN label is
> then processed by the egress PE identical to how it’s done with SR-MPLS or
> legacy mpls.
>
> So from an operator perspective such as Verizon that does make it
> attractive and an easy swap out migration or new green field implementation
> to migrate to SRv6 as all the customer Edge PE-CE protocols and
> encapsulation VPN related services L3 VPN. MVPN EVPN PBB VPWS e-tree e-lan
> e-line does not change for any services bottom labels.
>
> Is that true and if so that is a major design concern for migration of
> customers to a SRv6 core.
>
> With SR-TE now we would have native TE capabilities with SRv6 over SR-MPLS
> so that we can individually color each per vpn  flow to an SR-TE tunnel
> over SRv6 core.  I am stating that correctly that is the major benefit of
> SRv6 over SR-MPLS.
>
> Gyan
> Verizon Communications
> Cell phone 301 502-1347
>
>
> On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar 
> wrote:
>
>> Robert,
>>
>>
>>
>> Thank you very much for the explanation.
>>
>> With the L3VPN case,  there are nodes between Egress and Ingress PEs that
>> do look into the VPN label carried by the packets for VRF & IP lookup,
>> correct?
>>
>> I was just confused of the statement about “all nodes between Egress &
>> Ingress PE are SR unaware plain IP forwarding nodes”.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Linda
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Thursday, October 03, 2019 3:50 AM
>> *To:* Linda Dunbar 
>> *Cc:* draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
>> *Subject:* Re: [bess] WG adoption and IPR poll for
>> draft-dawra-bess-srv6-services-02
>>
>>
>>
>> Linda,
>>
>>
>>
>> SRv6 services is just a general term used here. Imagine one of such
>> service is L3VPN. VPN label (or pointer to it) is needed to be carried
>> somewhere in the packet as address space may be overlapping between VPN
>> customers and simple IP lookup will not be sufficient to determine VRF or
>> exit interface.
>>
>>
>>
>> One option which has been done and deployed is to encode it natively in
>> the packet and on ingress simply apply prodecures of IPv4 or IPv6
>> encapsulation - RFC4797 and RFC7510
>>
>>
>>
>> The other new option is to take the VPN label or VPN demux value and
>> encode it in SRH or in DO.
>>
>>
>>
>> Now which option to choose is left for the operator to decide likely
>> depending on a lot of other factors involved.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
>> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
>> wrote:
>>
>> I support WG adoption of the draft, with the following questions. Hope
>> authors can help to explain:
>>
>>
>>
>> Section 1 Introduction states that the underlay between the Ingress and
>> Egress only needs to support plain IPv6
>>
>> Forwarding. Those plain IPv6 routers don't need to understand the SR
>> policies

Re: [bess] Questions to draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Hi Linda,

Nope. Nodes except egress have any reason to look at VPN label. That label
has only local significance on egress.

Thx,
R.

On Thu, Oct 3, 2019 at 4:45 PM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the explanation.
>
> With the L3VPN case,  there are nodes between Egress and Ingress PEs that
> do look into the VPN label carried by the packets for VRF & IP lookup,
> correct?
>
> I was just confused of the statement about “all nodes between Egress &
> Ingress PE are SR unaware plain IP forwarding nodes”.
>
>
>
> Thanks,
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Thursday, October 03, 2019 3:50 AM
> *To:* Linda Dunbar 
> *Cc:* draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
> *Subject:* Re: [bess] WG adoption and IPR poll for
> draft-dawra-bess-srv6-services-02
>
>
>
> Linda,
>
>
>
> SRv6 services is just a general term used here. Imagine one of such
> service is L3VPN. VPN label (or pointer to it) is needed to be carried
> somewhere in the packet as address space may be overlapping between VPN
> customers and simple IP lookup will not be sufficient to determine VRF or
> exit interface.
>
>
>
> One option which has been done and deployed is to encode it natively in
> the packet and on ingress simply apply prodecures of IPv4 or IPv6
> encapsulation - RFC4797 and RFC7510
>
>
>
> The other new option is to take the VPN label or VPN demux value and
> encode it in SRH or in DO.
>
>
>
> Now which option to choose is left for the operator to decide likely
> depending on a lot of other factors involved.
>
>
>
> Thx,
>
> R.
>
>
>
> On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
> wrote:
>
> I support WG adoption of the draft, with the following questions. Hope
> authors can help to explain:
>
>
>
> Section 1 Introduction states that the underlay between the Ingress and
> Egress only needs to support plain IPv6
>
> Forwarding. Those plain IPv6 routers don't need to understand the SR
> policies encoded in the payload, correct?
>
> Why need Ingress PE to encapsulate the policy sent by egress PE if all the
> nodes between them are plain IPv6 routers?
>
>
>
> Which PE is to enforce the SR policy?
>
> If the policies are for the egress to enforce, why can't the egress PE
> simply enforce the policy instead of asking ingress node to encapsulate the
> policy in the packet header? Which has the drawback of extra header bits in
> packets.
>
>
>
> Linda Dunbar
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
> *Date: *Friday, September 27, 2019 at 4:00 AM
> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" 
> *Subject: *WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
> *Resent-From: *
> *Resent-To: *, , <
> pbris...@cisco.com>, Swadesh Agrawal , <
> daniel.vo...@bell.ca>, , , <
> rob...@raszuk.net>, , <
> satoru.matsush...@g.softbank.co.jp>, , <
> jorge.raba...@nokia.com>
> *Resent-Date: *Friday, September 27, 2019 at 4:00 AM
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dawra-bess-srv6-services%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7Ccda46858450b47cddd2908d747deab0f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637056893990134792=KplKMUlBMxL1hSt2ZMbYHpChddEsDhTRrUOLH7e7gaQ%3D=0>
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Robert Raszuk]

Linda,

SRv6 services is just a general term used here. Imagine one of such
service is L3VPN. VPN label (or pointer to it) is needed to be carried
somewhere in the packet as address space may be overlapping between VPN
customers and simple IP lookup will not be sufficient to determine VRF or
exit interface.

One option which has been done and deployed is to encode it natively in the
packet and on ingress simply apply prodecures of IPv4 or IPv6 encapsulation
- RFC4797 and RFC7510

The other new option is to take the VPN label or VPN demux value and encode
it in SRH or in DO.

Now which option to choose is left for the operator to decide likely
depending on a lot of other factors involved.

Thx,
R.

On Thu, Oct 3, 2019 at 5:52 AM Linda Dunbar 
wrote:

> I support WG adoption of the draft, with the following questions. Hope
> authors can help to explain:
>
>
>
> Section 1 Introduction states that the underlay between the Ingress and
> Egress only needs to support plain IPv6
>
> Forwarding. Those plain IPv6 routers don't need to understand the SR
> policies encoded in the payload, correct?
>
> Why need Ingress PE to encapsulate the policy sent by egress PE if all the
> nodes between them are plain IPv6 routers?
>
>
>
> Which PE is to enforce the SR policy?
>
> If the policies are for the egress to enforce, why can't the egress PE
> simply enforce the policy instead of asking ingress node to encapsulate the
> policy in the packet header? Which has the drawback of extra header bits in
> packets.
>
>
>
> Linda Dunbar
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
> *Date: *Friday, September 27, 2019 at 4:00 AM
> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" 
> *Subject: *WG adoption and IPR poll for draft-dawra-bess-srv6-services-02
> *Resent-From: *
> *Resent-To: *, , <
> pbris...@cisco.com>, Swadesh Agrawal , <
> daniel.vo...@bell.ca>, , , <
> rob...@raszuk.net>, , <
> satoru.matsush...@g.softbank.co.jp>, , <
> jorge.raba...@nokia.com>
> *Resent-Date: *Friday, September 27, 2019 at 4:00 AM
>
>
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Friday 11th October 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
> 
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Comment at the mic

[Robert Raszuk]

Hey Keyur,

I would like to share my perspective on your comment made at the BESS
yesterday.

What you pointed out that VPN demux should be removed or renewed when we
rewrite bgp next hop is very true in 4364 world or even in EVPN world where
VPN label is of local significance.

But in Srihari's proposal VPN demux may be of domain wide significance
hence mandating its removal at each EBGP boundary in the spec would be a
bad hint.

See with SID indicating to which VRF packet belongs applied consistently by
say NMS your option C becomes seamless without any "next-hop-unchanged"
hacks nor making PE-PE for multihomed sites failover requires any fancy
shadow LFIBs or control plane "taps" into updates which just pass by.

So while in general my personal opinion is that we do not need yet one more
way of  protocol encoding to accomplish L3VPNs which already is shipping in
the form of 4364 and EVPN standards if WG decides to proceed let's learn
from the past experience here.

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

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

Stephane,

Sure you can send two NHs next to each other. But my main question is what
should the receiver of such "thing" do ? Which next hop is more important
to be actually used in forwarding ? Based on what elements such decision is
made ...

If you know some history and can share it here iI think it may be useful
for others.

Btw which implementation sends two :) ? Should not be a big secret I
suppose.

Thx,
R.

On Fri, Jun 28, 2019 at 9:48 AM  wrote:

> Hi Robert,
>
>
>
> There are implementations which set two NHs, here is a capture:
>
>
>
> Update Message (2), length: 150
>
>   Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
>
> AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
>
> nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0),
> fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
>
>   RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::/56,
> label:1313 (bottom)
>
>   RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::1/128,
> label:1314 (bottom)
>
>   Origin (1), length: 1, Flags [T]: IGP
>
>   AS Path (2), length: 6, Flags [T]: 1
>
>   Extended Community (16), length: 8, Flags [OT]:
>
> target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)
>
>
>
> Note that this behavior caused some interop issues with another vendor who
> partially supported RFC4659.
>
>
>
> Brgds,
>
>
>
>
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 27, 2019 12:50
> *To:* Xiejingrong
> *Cc:* softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org;
> bess@ietf.org; i...@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> > Back to my suggestion: implementation should interpret nexthop RD+IPv4
> and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6
> the same.
>
>
>
> When elements of BGP UPDATE message are being parsed code must know what
> to expect. Note that we are dealing here with deployed SAFI 128 for nearly
> 20 years.
>
>
>
> So today there are two ways to know what format of next hop is in
> MP_REACH:
>
>
>
> a) Inferring it from AFI/SAFI per section 3 of RFC4760
>
>
>
> or (in addition to the above coarse assumption)
>
>
>
> b) Inferring it from the discrete value of next hop length field as
> defined in section 3 of RFC5549
>
>
>
> Note that if we would be defining new SAFI we can write anything we like
> to the rules of constructing the update message. But here again we are
> dealing with something which is deployed so sort of operating on the plane
> in flight.
>
>
>
> If implementation can infer next hop type from length we are safe to
> define all sections to have next hop length = 16 octets and be done. But if
> there are some implementations which would only take AFI/SAFI to check if
> the next hop is correct or even further to check if the next hop length is
> correct then we have a problem.
>
>
>
> /* Btw this notion of next hop length = 32 is bizarre ! I have never seen
> any BGP implementation sending two next hops (global IPv6 address followed
> by link local IPv6 address) not I am able to find any docs describing how
> any BGP stack would handle it. IMHO we should move this 32 next hop length
> to historic asap. */
>
>
>
> To the msg from Martin,
>
>
>
> > maybe the WG would like to reach a conclusion on how to treat that
> erratum:
>
> > http://www.rfc-editor.org/errata/eid5738
>
>
>
> I would vote to reject the errata. There is no value of stuffing 8 octet
> of zeros in the next hop field. If the RFC got defined in 2012 that really
> means that most implementations are capable of inferring next hop format
> from the length field - which is very good. Accepting the errata would be a
> step backwords.
>
>
>
> Thx,
> R.
>
>
>
> On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong  > wrote:
>
> Thanks for the RFC historical lessons.
>
> --there was historically some assumption that next hop must be of the same
> AF as prefix.
>
> --RFC 2858 says that Next Hop field should match AFI. On the other hand,
> RFC 4760 says that Next Hop Field should match combination of AFI/SAFI.
>
> --authors of RFC 4364 were trying to make it consistent with 4760.
>
> --Also, drafts of RFC 4364 and RFC 4760 were being developed practically
> at the same time period.
>
>
>
> The problem is clear, the nexthop field has been inconsistent between
> different L3VPN/MVPN 

Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

My vote - Reject.

Justification:

Irrespective if we would reject or accept the erratum implementations must
be able to handle 10 years old RFC so must be able to properly recognize
the next hop to be either of length 16 or 24. (I am putting aside the 32/48
invention).

So that means that next hop length should be used to recognize format of
the next hop. That with the fact that stuffing next hop address with
useless 64 zeros in the front leads me to believe that if we are to produce
any erratums it should be the other way around ... we should replace all
documents which call for having next hops full of zeros in the front to
normalize it to consist of just real IPv4 or IPv6 single address.

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan 
wrote:

> Hi all,
>
> Can the WG reach a conclusion on how to treat that erratum related to
> RFC5549:
>
> https://www.rfc-editor.org/errata/eid5253
>
> Thanks,
> Shunwan
>
> -Original Message-
> From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> Sent: Thursday, June 27, 2019 6:37 PM
> To: Xiejingrong ; Alexander Okonnikov <
> alexander.okonni...@gmail.com>; Robert Raszuk ;
> bess@ietf.org
> Cc: softwi...@ietf.org; i...@ietf.org
> Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
> since we are discussing that topic,
>
> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738
>
> Thanks
> -m
>
> Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> > Thanks for the RFC historical lessons.
> >
> > --there was historically some assumption that next hop must be of the
> > same AF as prefix.
> >
> > --RFC 2858 says that Next Hop field should match AFI. On the other
> > hand, RFC 4760 says that Next Hop Field should match combination of
> AFI/SAFI.
> >
> > --authors of RFC 4364 were trying to make it consistent with 4760.
> >
> > --Also, drafts of RFC 4364 and RFC 4760 were being developed
> > practically at the same time period.
> >
> > The problem is clear, the nexthop field has been inconsistent between
> > different L3VPN/MVPN scenarios and different implementations in the
> > long history.
> >
> >  is the latest draft, but it has
> > different nexthop in section 3.1 to 3.4, in the year 2019.
> >
> > Back to my suggestion: implementation should interpret nexthop RD+IPv4
> > and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop
> > IPv6 the same.
> >
> > I think it may be helpful for  to
> > add the above text, and update RFC4364/4659/4760/5549, to eliminate
> > the worries about interoperation. is there any worries about
> > interoperation ?
> >
> > Thanks
> >
> > Jingrong
> >
> > *From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
> > *Sent:* Wednesday, June 26, 2019 9:38 PM
> > *To:* Robert Raszuk 
> > *Cc:* UTTARO, JAMES ; Xiejingrong
> > ; softwi...@ietf.org; i...@ietf.org;
> > ian.far...@telekom.de; bess@ietf.org; ianfar...@gmx.com
> > *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> > Address coding for IPv4 VPN over IPv6 Core in RFC5549
> >
> > Hi Robert,
> >
> > Sorry, I was not so precise :-) Of course, RD part in Next Hop is not
> > copied from RD of NLRI, but zeroed. I was trying to explain why Next
> > Hop field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address)
> > rather than just IP.
> >
> > Thank you!
> >
> >
> >
> >
> >
> > ___
> > Idr mailing list
> > i...@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
> ___
> Softwires mailing list
> softwi...@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

> Back to my suggestion: implementation should interpret nexthop RD+IPv4
and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6
the same.

When elements of BGP UPDATE message are being parsed code must know what to
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined
in section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to
the rules of constructing the update message. But here again we are dealing
with something which is deployed so sort of operating on the plane in
flight.

If implementation can infer next hop type from length we are safe to define
all sections to have next hop length = 16 octets and be done. But if there
are some implementations which would only take AFI/SAFI to check if the
next hop is correct or even further to check if the next hop length is
correct then we have a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen
any BGP implementation sending two next hops (global IPv6 address followed
by link local IPv6 address) not I am able to find any docs describing how
any BGP stack would handle it. IMHO we should move this 32 next hop length
to historic asap. */

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that
erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of
zeros in the next hop field. If the RFC got defined in 2012 that really
means that most implementations are capable of inferring next hop format
from the length field - which is very good. Accepting the errata would be a
step backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong  wrote:

> Thanks for the RFC historical lessons.
>
> --there was historically some assumption that next hop must be of the same
> AF as prefix.
>
> --RFC 2858 says that Next Hop field should match AFI. On the other hand,
> RFC 4760 says that Next Hop Field should match combination of AFI/SAFI.
>
> --authors of RFC 4364 were trying to make it consistent with 4760.
>
> --Also, drafts of RFC 4364 and RFC 4760 were being developed practically
> at the same time period.
>
>
>
> The problem is clear, the nexthop field has been inconsistent between
> different L3VPN/MVPN scenarios and different implementations in the long
> history.
>
>
>
>  is the latest draft, but it has
> different nexthop in section 3.1 to 3.4, in the year 2019.
>
>
>
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the
> same.
>
>
>
> I think it may be helpful for  to add
> the above text, and update RFC4364/4659/4760/5549, to eliminate the worries
> about interoperation. is there any worries about interoperation ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
>
>
> *From:* Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk 
> *Cc:* UTTARO, JAMES ; Xiejingrong ;
> softwi...@ietf.org; i...@ietf.org; ian.far...@telekom.de; bess@ietf.org;
> ianfar...@gmx.com
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Robert,
>
>
>
> Sorry, I was not so precise :-) Of course, RD part in Next Hop is not
> copied from RD of NLRI, but zeroed. I was trying to explain why Next Hop
> field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) rather than
> just IP.
>
>
>
> Thank you!
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

Hi Alex,

> My understanding is follow: RD is encoded in Next Hop field

That is subtle misinterpretation of the 4364 :)

The text says:

"When a PE router distributes a VPN-IPv4 route via BGP, it uses its  own
address as the "BGP next hop".  This address is encoded as a VPN-IPv4
address with an RD of 0."

That can be read as:

A) Next hop field has prepended zeros to match the NLRI format of 8 octet
RD + 4 octet IPv4 (for IPv4 case)

B) Next hop is of format RD:IPv4 where RD=0

My recollection and number of direct discussions with authors of
both2547/4364 & 4760 at that time leads me to believe we are dealing with
A. Of course anyone can see option B as valid, but at the end of the day it
is the same on the wire :)

So I am not sure what exactly the problem or the question we are trying to
answer is :)

Cheers,
R.






On Wed, Jun 26, 2019 at 3:22 PM Alexander Okonnikov <
alexander.okonni...@gmail.com> wrote:

> Hi,
>
> My understanding is follow: RD is encoded in Next Hop field, because
> authors of RFC 4364, while referring to RFC 2858, were trying to make it
> consistent with RFC 4760 (obsoletes RFC 2858). RFC 2858 says that Next Hop
> field should match AFI. On the other hand, RFC 4760 says that Next Hop
> Field should match combination of AFI/SAFI. Also, drafts of RFC 4364 and
> RFC 4760 were being developed practically at the same time period.
>
> 26 июня 2019 г., в 16:05, UTTARO, JAMES  написал(а):
>
> *+1*
>
> *From:* Idr  *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong 
> *Cc:* i...@ietf.org; ian.far...@telekom.de; ianfar...@gmx.com;
> softwi...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
> All,
>
> RD is a property of the NLRI not next hop. I am not sure where in this
> thread or some spec someone came to the conclusion that next hop field
> should contain an RD. RD is not useful there and should never be part of
> any next hop field.
>
> Remember RD role is to make prefix unique - that's it - no more no less.
> Next hop uniqness is given by architecture and there is no need to make it
> unique.
>
> In some cases when we need to carry IPv4 address in IPv6 next hop field
> (there was historically some assumption that next hop must be of the same
> AF as prefix) we prepend to it numerical zeros.
>
> Thx,
> R.
>
>
>
>
>
> On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong 
> wrote:
>
> Hi folks,
>
> I guess this is an inconsistency due to past carelessness. Is there anyone
> can tell us the history of this inconsistency ?
> RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6
> network) both require to use RD+IP(v4 or v6 respectively) as nexthop.
> RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as
> nexthop.
> This same question also occur in MVPN: RFC6515, which talks about MVPN6
> over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6
> without RD as nexthop (see below).
>The purpose of this document is to make clear that whenever a PE
>address occurs in an MCAST-VPN route (whether in the NLRI or in an
>attribute), the IP address family of that address is determined by
>the length of the address (a length of 4 octets for IPv4 addresses, a
>length of 16 octets for IPv6 addresses), NOT by the AFI field of the
>route.
>
> My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop
> IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
> The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate
> can meet between different implementations.
> Need a new draft to clarify this and to give a guide on further FooService
> over FooNetwork ?
>
> Thanks
> Jingrong
>
> *From:* Softwires [mailto:softwires-boun...@ietf.org] *On Behalf Of *
> ian.far...@telekom.de
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan ; ianfar...@gmx.com
> *Cc:* softwi...@ietf.org; bess@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
> Hi Shunwan,
>
> I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and
> I can find nothing about using VPN-IPv6 for encoding the next-hop. Section
> 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes
> with a GU and LL address.
>
> Can you point me to the text that gives you the impression that VPN-IPv6
> is correct?
>
> Note – I see that there is reported Errata on RFC5549, (not verified)
> saying that the length should be 24 or 48 to include the RD. However, as
> mentioned a

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

And just to self complete the last sentence ...

The same leading zeros were also added to SAFI 128  in the next hop field
as to match the length of RD:IP prefix of the L3VPN NLRI. Original 2547 or
subsequent 4364 did not define explicitly that the size of the next hop
could be inferred from the nh length field - just took verbatim from 4760
that next hop is identified by AFI/SAFI of the NLRI itself .

But in general MP-BGP spec does not limit protocol designers. When you
define a new SAFI you are free to say that format of next hop will be
inferred from its length field or that next hop may not be present at all
as it does not make sense for a given SAFI (ref 5575) and that in turn will
be indicated by zero nh length

Many thx,
R.


On Wed, Jun 26, 2019 at 3:06 PM UTTARO, JAMES  wrote:

> *+1*
>
>
>
> *From:* Idr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong 
> *Cc:* i...@ietf.org; ian.far...@telekom.de; ianfar...@gmx.com;
> softwi...@ietf.org; bess@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> All,
>
>
>
> RD is a property of the NLRI not next hop. I am not sure where in this
> thread or some spec someone came to the conclusion that next hop field
> should contain an RD. RD is not useful there and should never be part of
> any next hop field.
>
>
>
> Remember RD role is to make prefix unique - that's it - no more no less.
> Next hop uniqness is given by architecture and there is no need to make it
> unique.
>
>
>
> In some cases when we need to carry IPv4 address in IPv6 next hop field
> (there was historically some assumption that next hop must be of the same
> AF as prefix) we prepend to it numerical zeros.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong 
> wrote:
>
> Hi folks,
>
>
>
> I guess this is an inconsistency due to past carelessness. Is there anyone
> can tell us the history of this inconsistency ?
>
> RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6
> network) both require to use RD+IP(v4 or v6 respectively) as nexthop.
>
> RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as
> nexthop.
>
> This same question also occur in MVPN: RFC6515, which talks about MVPN6
> over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6
> without RD as nexthop (see below).
>
>The purpose of this document is to make clear that whenever a PE
>
>address occurs in an MCAST-VPN route (whether in the NLRI or in an
>
>attribute), the IP address family of that address is determined by
>
>the length of the address (a length of 4 octets for IPv4 addresses, a
>
>length of 16 octets for IPv6 addresses), NOT by the AFI field of the
>
>route.
>
>
>
> My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop
> IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
>
> The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate
> can meet between different implementations.
>
> Need a new draft to clarify this and to give a guide on further FooService
> over FooNetwork ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Softwires [mailto:softwires-boun...@ietf.org] *On Behalf Of *
> ian.far...@telekom.de
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan ; ianfar...@gmx.com
> *Cc:* softwi...@ietf.org; bess@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Shunwan,
>
>
>
> I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and
> I can find nothing about using VPN-IPv6 for encoding the next-hop. Section
> 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes
> with a GU and LL address.
>
>
>
> Can you point me to the text that gives you the impression that VPN-IPv6
> is correct?
>
>
>
> Note – I see that there is reported Errata on RFC5549, (not verified)
> saying that the length should be 24 or 48 to include the RD. However, as
> mentioned above, the supporting text in multiple places in the RFC and its
> references support the use of an IPv6 address (or 2) with no RD at 16 or 32
> bytes, so this does seem to be the intention of the document as written.
>
> https://www.rfc-editor.org/errata_search.php?rfc=5549
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5549=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=U

Re: [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

All,

RD is a property of the NLRI not next hop. I am not sure where in this
thread or some spec someone came to the conclusion that next hop field
should contain an RD. RD is not useful there and should never be part of
any next hop field.

Remember RD role is to make prefix unique - that's it - no more no less.
Next hop uniqness is given by architecture and there is no need to make it
unique.

In some cases when we need to carry IPv4 address in IPv6 next hop field
(there was historically some assumption that next hop must be of the same
AF as prefix) we prepend to it numerical zeros.

Thx,
R.





On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong  wrote:

> Hi folks,
>
>
>
> I guess this is an inconsistency due to past carelessness. Is there anyone
> can tell us the history of this inconsistency ?
>
> RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6
> network) both require to use RD+IP(v4 or v6 respectively) as nexthop.
>
> RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as
> nexthop.
>
> This same question also occur in MVPN: RFC6515, which talks about MVPN6
> over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6
> without RD as nexthop (see below).
>
>The purpose of this document is to make clear that whenever a PE
>
>address occurs in an MCAST-VPN route (whether in the NLRI or in an
>
>attribute), the IP address family of that address is determined by
>
>the length of the address (a length of 4 octets for IPv4 addresses, a
>
>length of 16 octets for IPv6 addresses), NOT by the AFI field of the
>
>route.
>
>
>
> My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop
> IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
>
> The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate
> can meet between different implementations.
>
> Need a new draft to clarify this and to give a guide on further FooService
> over FooNetwork ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Softwires [mailto:softwires-boun...@ietf.org] *On Behalf Of *
> ian.far...@telekom.de
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan ; ianfar...@gmx.com
> *Cc:* softwi...@ietf.org; bess@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Shunwan,
>
>
>
> I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and
> I can find nothing about using VPN-IPv6 for encoding the next-hop. Section
> 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes
> with a GU and LL address.
>
>
>
> Can you point me to the text that gives you the impression that VPN-IPv6
> is correct?
>
>
>
> Note – I see that there is reported Errata on RFC5549, (not verified)
> saying that the length should be 24 or 48 to include the RD. However, as
> mentioned above, the supporting text in multiple places in the RFC and its
> references support the use of an IPv6 address (or 2) with no RD at 16 or 32
> bytes, so this does seem to be the intention of the document as written.
>
> https://www.rfc-editor.org/errata_search.php?rfc=5549
>
>
>
> Thanks,
>
> Ian
>
>
>
> *From: *Softwires  on behalf of Zhuangshunwan
> 
> *Date: *Tuesday, 25. June 2019 at 13:18
> *To: *"ianfar...@gmx.com" 
> *Cc: *"softwi...@ietf.org" , "bess@ietf.org" <
> bess@ietf.org>
> *Subject: *Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Ian,
>
>
>
> Thanks for your response!
>
>
>
> The opinion I have collected is:
>
> Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning
> with an 8-octet RD and ending with a 4-octet IPv4 address.
>
> Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning
> with an 8-octet RD and ending with a 16-octet IPv6 address.
>
> When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural
> way to encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning
> with an 8-octet RD and ending with a 16-octet IPv6 address) .
>
>
>
> I believe this is not just a minority opinion, and some of the current
> implementations are also doing this way.
>
>
>
> I hope that the WGs can give a consistent opinion on this issue and avoid
> interoperability problem in the future.
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> *From:* ianfar...@gmx.com [mailto:ianfar...@gmx.com ]
> *Sent:* Monday, June 24, 2019 8:08 PM
> *To:* Zhuangshunwan 
> *Cc:* bess@ietf.org; softwi...@ietf.org
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi,
>
>
>
> My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as
> an IPv6 address:
>
>
>
>The BGP speaker receiving the advertisement MUST use the Length of
>
>Next Hop Address field to determine which network-layer protocol the
>
>next hop address belongs to.  When the Length of Next Hop 

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Robert Raszuk]

Hi Jeffrey,

Isn't this just a matter of how you would be implementing "tunneling" ?

For vast majority of decapsulations there is no state as such, but it is
just part of one of normal switching vectors in the router.

Best,
R.

On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang  The receiver PE cannot keep its state to receive on both tunnels forever.
> After some time, it has to leave the old tunnel.
>
> Jeffrey
>
> > -Original Message-
> > From: Xiejingrong [mailto:xiejingr...@huawei.com]
> > Sent: Wednesday, January 23, 2019 9:09 PM
> > To: Jeffrey (Zhaohui) Zhang ;
> draft-ietf-bess-mvpn-expl-
> > tr...@ietf.org
> > Cc: bess@ietf.org
> > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> > Action: draft-ietf-bess-mvpn-expl-track-13.txt
> >
> > Hi Jeffrey,
> >
> > Thanks for the explaination.
> > I have the same understanding "the text in RFC6625 is really/mainly about
> > which tunnel to send/receive on in a steady state."
> > What confusing me is the "which tunnel to receive" decision, obviously on
> > receiver site PE.
> >
> > In my opinion, the receiver site PE should not do the decision, but be
> prepared
> > to *any possible tunnel* that will be used by the sender site PE for a
> specific
> > (S,G) flow.
> > Even in a steady state the sender site PE are using the (S,G)
> PMSI-tunnel for a
> > (S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the
> > receiver site PE.
> >
> > Below is the errata report I have raised, and I hope it can be clarified.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
> > 2Deditor.org_errata_eid5605=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK
> > -
> > ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=uchRmclZ5z8wB9eN53Kr24c9zLtM9RBRe8OnA3FK1fM=cbCycqc2jZy8SjT
> > LHS4AEL_UhljIoaGGWAnycB0VvrY=
> >
> >
> > -Original Message-
> > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
> > Sent: Thursday, January 24, 2019 12:32 AM
> > To: Xiejingrong ; draft-ietf-bess-mvpn-expl-
> > tr...@ietf.org
> > Cc: bess@ietf.org
> > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> > Action: draft-ietf-bess-mvpn-expl-track-13.txt
> >
> > Hi Jingrong,
> >
> > You're right that to avoid disruption and duplication a switchover delay
> is
> > needed on the source PE and desired on the receiver PE, and that means
> the
> > forwarding state needs to accommodate that.
> >
> > However, the text is in RFC6625 is really/mainly about which tunnel to
> > send/receive on in a steady state. That's not explicitly spelled out,
> but that's
> > the intention per my understanding.
> >
> > To be more accurate, the text is about which PMSI route to match. In
> theory a
> > PMSI can be instantiated with one particular tunnel at one time and then
> > switch to another tunnel. In that case the PMSI route is updated with a
> > different PTA - the match to sending/receiving does not change yet the
> > switchover delay referred to RFC6513 still applies.
> >
> > Jeffrey
> >
> > > -Original Message-
> > > From: Xiejingrong [mailto:xiejingr...@huawei.com]
> > > Sent: Tuesday, January 22, 2019 8:47 PM
> > > To: Jeffrey (Zhaohui) Zhang ;
> > > draft-ietf-bess-mvpn-expl- tr...@ietf.org
> > > Cc: bess@ietf.org
> > > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess]
> > > I-D
> > > Action: draft-ietf-bess-mvpn-expl-track-13.txt
> > >
> > > Hi Jeffrey,
> > >
> > > The sender PE need to work on (*,*) tunnel for a while (switch-over
> > > timer) and then switch to the (S,G) tunnel.
> > >
> > > To quote RFC6513 section 7.1.1
> > >The decision to bind a particular C-flow (designated as (C-S,C-G))
> to
> > >a particular P-tunnel, or to switch a particular C-flow to a
> > >particular P-tunnel, is always made by the PE that is to transmit
> the
> > >C-flow onto the P-tunnel.
> > >
> > >When a C-flow is switched from one P-tunnel to another, the purpose
> > >of running a switch-over timer is to minimize packet loss without
> > >introducing packet duplication.
> > >
> > > Jingrong
> > >
> > > -Original Message-
> > > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
> > > Sent: Saturday, January 12, 2019 3:29 AM
> > > To: Xiejingrong ; draft-ietf-bess-mvpn-expl-
> > > tr...@ietf.org
> > > Cc: bess@ietf.org
> > > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess]
> > > I-D
> > > Action: draft-ietf-bess-mvpn-expl-track-13.txt
> > >
> > > Jingrong,
> > >
> > > > It is determined by the sender site PE whether to steer the flow of
> > > > (C-S, C-G)
> > > into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE
> > > should work correctly in any case.
> > >
> > > Why would the sender PE send into (*, *) when there is a match for
> (S,G)?
> > >
> > > Jeffrey
> > >
> > > > -Original Message-
> > > > From: Xiejingrong [mailto:xiejingr...@huawei.com]
> > > > Sent: Thursday, January 10, 2019 11:10 PM
> > > > 

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Robert Raszuk]

Hi Linda,

There are some key differences: Skype and CDN overlay companies don’t have
> any intension to interoperate, but networking needs interoperability.
>

There is no issue about interoperability. Observe that that each endpoint
can today seamlessly be a member of N different SD-WAN orchestration
systems. In fact wise deployment requires that to provide sufficient
robustness on a per site SD-WAN VPN basis.

 Adding a new BGP SAFI is 1% of implementation burden of adding a new
> protocol.
>

Look ... BGP RRs got loaded with carrying dynamic IGP data. Now we are
facing to load it with IPSec data. Where does this end ?

IMHO IDR WG should evaluate each proposal for extension in the view of what
elements of BGP protocol given extension attempts to augment. If this is
solely for transporting opaque data such proposal should be either denied
or ensured by MUST that is has to run on different instance of real BGP
(just to accomodate your 1% code extension) as proposed
in draft-raszuk-mi-bgp-00


4. Registry of Data on AWS etc...
>
> [Linda] sure if AWS is interested in participating to make the needed
> changes. More work is needed to make AWS Data registry to communicate our
> existing BGP?
>

AWS or Azure or GCP should not play any role in that. Those would be purely
compute infra providers taking no responsibility for what data is being
exchanged there. Obviously some vendor neutral entitiy should operate it.
Likely some ICANN analogy on how DNS is being run today.

But as mentioned above for SD-WAN I really do not see a problem. Any open
or closed SD-WAN orchestration with just few clicks of the mouse can add or
delete sites and such sites can participate in more then one SD-WAN. In
fact paying few dollars per month per site allows you to outsource your WAN
networking costs for peanuts as well as benefit from a lot of non limited
custom features between SD-WAN providers.

Do we really want now to limit that innovation by putting them onto IETF
tracks (regardless of WG chosen to own this) ?

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

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Robert Raszuk]

Hi Linda,

I have one comment to proposed encoding and one overall observation.

*Comment: *

Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type.
Possible values are:  NAT Type.without NAT; 1:1 static NAT; Full Cone;
Restricted Cone; Port Restricted Cone; or Symmetric.

You very nicely listed all nat types except one: "unknown" :) Why - Let's
notice that in the other part of the text you state that information of the
NAT type may be obtained from STUN server "can inquire". So if use of STUN
server is optional then there is possibility that there is none and end
point would not know about the NAT type it is traversing.

*Observation: *

This seems to be yet one more time we see proposal of "let's ride on BGP as
we need to exchange endpoint discovery data point to point in a realiable
way". I see zero need in this proposal why BGP is required here as opposed
to any piece of code which can deliver data between two or more endpoints.

Seeing those proposals it puzzles me a lot why skype or hangout are not
using BGP ... after all video or voice call setup does require exchange of
endpoint data. Likewise another unknown mystery is why SMTP is not riding
on BGP too ?

Yes overall we are missing now pretty much every day a global distributed
system to exchange endpoint data in a dynamic way.

Before we proceed on this or any other similar BGP extension I would highly
appreciate some discussion on why below alternatives or other new similar
proposals can be used instead of BGP for the described applications.

1. LISP mapping plane
2. Products of IDentity Enabled Networks WG
3. DynamicDNS
4. Registry of Data on AWS
etc...

Thx,
Robert.


On Tue, Oct 30, 2018 at 5:19 PM Linda Dunbar 
wrote:

> IDR group, BESS group,
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/
> specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s
> capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes
> through third party untrusted networks.
>
>
>
> draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes
> to exchange key and policy to create private pair-wise IPsec Security
> Associations without IKEv2 point-to-point signaling or any other direct
> peer-to-peer session establishment messages.
>
>
>
> I think those two solutions are not conflicting with each other. Actually
> they are compliment to each other to some degree. For example,
>
> -the Re-key mechanism described by
> draft-sajassi-bess-secure-evpn-00 can be utilized by
> draft-dunbar-idr-bgp-sdwan-overlay-ext
>
> -The SD-WAN Overlay SAFI can be useful to simplify the process on
> RR to re-distribute the Tunnel End properties to authorized peers.
>
> -When SD-WAN edge nodes use private address, or no IP address,
> NAT properties for the end points distribution described
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
>
> -The secure channel between SD-WAN edge nodes and RR described by
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
>
>
>
> Any thoughts?
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[Robert Raszuk]

Support

On Tue, Oct 30, 2018, 09:22  Hi WG,
>
>
>
> This email begins a two-week poll for BESS working group adoption
> draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]
>
>
>
> Please review the draft and post any comments to the BESS working group
> list, stating whether or not you support adoption.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> The poll for working group adoption closes on Tue 13th November.
>
>
>
> Regards,
>
> Stéphane and Matthew
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/
>
>
>
>
>
>
>
>
>
>
>
> [image: Orange logo] 
>
>
>
> *Stephane Litkowski *
> Network Architect
> Orange/SCE/EQUANT/OINIS/NET
>
> Orange Expert Future Networks
>
> phone: +33 2 23 *06* 49 83
> 
>  NEW !
> mobile: +33 6 71 63 27 50
> 
>  NEW !
> stephane.litkow...@orange.com
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)

[Robert Raszuk]

Hi Benjamin,

Yes now I see your point and all I can do is to agree with it.

As you know the story with right terminology is evolved to be even more
"funny". The real true and encrypted VPNs in the Internet are called SD-WAN
these days without any indication that there is privacy assurance while VPN
term is merely separating default IP reachability between parties if we
look at say L3VPNs. Sure there are also point to point IPSec VPNs which do
either encrypt or assure not compromised payload delivery.

So I guess indeed terminology is pretty confusing - and in fact it is
confusing even to technical people who are just not that ultimately
familiar with RFC4364 protocol and vendor's implementation details. Also
let's note that RFC4364 is often used outside of Internet and perhaps there
in those enterprise private networks encryption is not that much of a
necessity.

> From my view as Security AD, it would be quite a shame if we ended up in
an
> Internet world where some corporate purchaser buys a product labelled
"VPN"
> thinking it will protect (encrypt) his company's data, when in fact it
only
> provides IP reachability separtaion.

Well I think the market is here to help us ...

Today I see use of L3VPNs from SPs as rather fading away. SD-WAN have clear
advantages from both technical and economical points of view that I am not
sure if struggle to either rename or add mandatory or even optional
encryption to RFC4364 is really worth the effort.

A bit side observation is that the example described above leads me to
believe that the main fundamental problem is that today IETF does not (at
least to the best of my knowledge) coordinate names for new protocols or
protocol extensions in any way. Anyone can invent his own name and once the
document passes WG validating its technical merits I have not heard of many
cases where IESG or IETF wide review would change the name itself of the
proposal. And maybe in some cases it should 

Kind regards,
Robert.


On Sat, Sep 15, 2018 at 2:51 AM Benjamin Kaduk  wrote:

> On Wed, Sep 12, 2018 at 10:29:49AM +0200, Robert Raszuk wrote:
> > Hi Benjamin,
> >
> > > A general comment that we've been making on lots of documents in this
> > > space is that it would be nice to be in a place where the acronym "VPN"
> > > implies transport encryption.
> >
> > Let me observe that for a lot of work in IETF term "VPN" does *not* imply
> > any form of either transport or payload encryption.
>
> I am aware that this is the current state, yes.  That's why I used the
> phrasing I did, namely, "it would be nice to be in a place", with the
> implication that we currently aren't.
>
> > In fact here the MVPN which is derivative of L3VPNs do not imply use of
> any
> > encryption at all.
> >
> > The term "VPN" here is really all about IP reachability separation.
> >
> > So with this in mind can you please clarify your above comment ?
>
> Sure!  In recent years, the IETF as a whole seems to have shifted toward
> placing a greater emphasis on the privacy protection of user data from "the
> network" (not the network operators, necessarily, but an attacker that has
> coopted or compromised core nodes).  This is, in some sense, the core point
> of RFC 7258.  With this renewed interest in "private" and "privacy"
> referring to obscuring user data from intermediates (i.e., encryption),
> using the same word "private" to refer to a different concept ("not
> shared", as the IP reachability separation embodies) can lead to confusion.
> This is particularly pronounced in the case of the acronym "VPN", when
> (encrypting) corporate VPNs are nigh-ubiquitous, and end users have
> (encrypting) VPNs to pierce firewalls that get in their way, avoid
> geographic-based content restrictions, and the like.
>
> While the network engineers and RFC authors know there are different
> contexts for the term in current usage, the popular media really does not,
> and there are many consumers of RFCs that are not intimately involved in
> their development.  So as a matter for the "good of the Internet", my
> position is that reducing this potential for confusion is desirable.
> From my view as Security AD, it would be quite a shame if we ended up in an
> Internet world where some corporate purchaser buys a product labelled "VPN"
> thinking it will protect (encrypt) his company's data, when in fact it only
> provides IP reachability separtaion.
>
> I don't have an alternative term I want to push for the "not shared" case
> (though just "Virtual Network" and its parallels to network virtualization
> does come to mind); even a passing mention that this instance 

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)

[Robert Raszuk]

Hi Benjamin,

> A general comment that we've been making on lots of documents in this
> space is that it would be nice to be in a place where the acronym "VPN"
> implies transport encryption.

Let me observe that for a lot of work in IETF term "VPN" does *not* imply
any form of either transport or payload encryption.

In fact here the MVPN which is derivative of L3VPNs do not imply use of any
encryption at all.

The term "VPN" here is really all about IP reachability separation.

So with this in mind can you please clarify your above comment ?

Kind regards,
Robert.


On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-mvpn-mib-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-mvpn-mib/
>
>
>
> --
> COMMENT:
> --
>
> A general comment that we've been making on lots of documents in this
> space is that it would be nice to be in a place where the acronym "VPN"
> implies transport encryption.  It's unclear that it's appropriate to
> request
> changes to this specific document toward that end, though.
>
> Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
> considerations in the list of address-related objects that may have
> privacy/security impact.  That list is predicated on being "objects with a
> MAX-ACCESS other than not-accessible", but all the instances of
> mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
> Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
> mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
> mvpnMrouteNextHopAddr.  (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
> and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)
>
> Perhaps using subsections to separate the various tables' descriptions
> would aid readability.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

[Robert Raszuk]

Hi Stefan,

On the topic of multitenancy in customer sites I completely agree with You.

I pointed that to the authors already ;)

But observe that if they also are targeting DCs as the draft says there is
clear need for multi tenancy on compute nodes. I guess they are trying to
cook two meals on the same fire.

But then this is a bit of head on collision course with Contrail 

Best,
R.

On Thu, Jun 14, 2018, 12:41  wrote:

> Hi Robert,
>
>
>
> Thanks for sharing your point of view. I think we just have a different
> reading/understanding of the goals.
>
> I do not disagree with what you say.
>
>
>
> I was not seeing this as an SD-WAN like solution. At least it is not
> presented this way.
>
> I understood the draft as how can I overcome some security concerns today
> with PPVPN.
>
>
>
> I’m fine to build automated VPNs over a public infra like Internet J
>
> If we want to make this solution more SDWAN like (I do not mean a full
> SDWAN solution), we need to involve more automation, especially setup of
> RRs and BGP sessions…
>
>
>
> Again, as I mentioned, the multitenancy is more a nice to have: most of
> customers do not need this.
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 14, 2018 11:13
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Ron Bonica; bess@ietf.org
> *Subject:* Re: [bess] New Version Notification for
> draft-rosen-bess-secure-l3vpn-00.txt
>
>
>
> Hello Stephane,
>
>
>
> I read the draft with deep interest. In my opinion I completely have
> opposite view to yours - "niche use case" - quite contrary connecting
> customer sites over open infrastructure have already started to happen in
> large scale globally.
>
>
>
> It is not about adding IPSec tunnel here and there - the crux is about
> automating it to accommodate very large scale deployments. Perhaps your
> comment is based on this specific point that IPSec today created manually
> is a niche and therefor automating it does not make sense. But this is not
> about it. It is about transition from SP operated L3VPNs into an
> alternative L3VPN paradigm.
>
>
>
> Yes I understand that the draft may not be very comfortable for SPs who's
> review comes from locking customer to MPLS-L3VPN backbone just like in the
> old days they were locking customer to Frame Relay or ATM backbones :).
>
>
>
> Maybe our definitions of niche is a bit different, but when I look at the
> market cap of SD-WAN vendors it seems like if you would call as niche an
> ant in the forest here we are watching an army of elephants entering the
> woods.
>
>
>
> Yes the draft is just first important step towards standards based open
> infra secure interconnects - it can not be treated as full SD-WAN spec as
> it is missing a lot of important functionalities today addressed in more or
> less proprietary way by any such vendor.
>
>
>
> The technology is not new too ...  since day one we had Carrier's Carrier
> solution when customers could exchange their routes directly. We also had
> tunnel encapsulation attribute in place where we could signal various
> parameters of given encap. However putting it all together as Eric did in
> this document is IMHO a very important step fwd especially coming under the
> umbrella of one specific affiliation :).
>
>
>
> I do support this work and I hope this is just one brick which we can
> start build on going forward standards based interoperable secure
> connectivity over open public IP infrastructure.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 14, 2018 at 8:17 AM,  wrote:
>
> Hi Ron,
>
> I have read quickly the document.
> I think the use case of having secure L3VPNs is valid and we already have
> all (or most of) the technology building blocks to do it.
> Now the draft takes a complete upside down approach comparing to our well
> known L3VPNs which are provider provisioned VPNs as you propose to build
> them at the CE side.
> This could be a valid approach but isn't it a niche use case ?
>
> Customer sites connected over the Internet is for sure a use case to
> handle, and we already to it today by establishing an IPSec tunnel towards
> an SP-PE, the tunnel ends in the customer VRF.
> Customer data must not be exposed: also a valid use case. We have some
> customers doing IPSec transport within MPLS VPN for some specific traffic..
> On the other hand, from an SP point of view, when core links are not fully
> trusted, MACSEC or IPS

Re: [bess] New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

[Robert Raszuk]

Hello Stephane,

I read the draft with deep interest. In my opinion I completely have
opposite view to yours - "niche use case" - quite contrary connecting
customer sites over open infrastructure have already started to happen in
large scale globally.

It is not about adding IPSec tunnel here and there - the crux is about
automating it to accommodate very large scale deployments. Perhaps your
comment is based on this specific point that IPSec today created manually
is a niche and therefor automating it does not make sense. But this is not
about it. It is about transition from SP operated L3VPNs into an
alternative L3VPN paradigm.

Yes I understand that the draft may not be very comfortable for SPs who's
review comes from locking customer to MPLS-L3VPN backbone just like in the
old days they were locking customer to Frame Relay or ATM backbones :).

Maybe our definitions of niche is a bit different, but when I look at the
market cap of SD-WAN vendors it seems like if you would call as niche an
ant in the forest here we are watching an army of elephants entering the
woods.

Yes the draft is just first important step towards standards based open
infra secure interconnects - it can not be treated as full SD-WAN spec as
it is missing a lot of important functionalities today addressed in more or
less proprietary way by any such vendor.

The technology is not new too ...  since day one we had Carrier's Carrier
solution when customers could exchange their routes directly. We also had
tunnel encapsulation attribute in place where we could signal various
parameters of given encap. However putting it all together as Eric did in
this document is IMHO a very important step fwd especially coming under the
umbrella of one specific affiliation :).

I do support this work and I hope this is just one brick which we can start
build on going forward standards based interoperable secure connectivity
over open public IP infrastructure.

Kind regards,
Robert.








On Thu, Jun 14, 2018 at 8:17 AM,  wrote:

> Hi Ron,
>
> I have read quickly the document.
> I think the use case of having secure L3VPNs is valid and we already have
> all (or most of) the technology building blocks to do it.
> Now the draft takes a complete upside down approach comparing to our well
> known L3VPNs which are provider provisioned VPNs as you propose to build
> them at the CE side.
> This could be a valid approach but isn't it a niche use case ?
>
> Customer sites connected over the Internet is for sure a use case to
> handle, and we already to it today by establishing an IPSec tunnel towards
> an SP-PE, the tunnel ends in the customer VRF.
> Customer data must not be exposed: also a valid use case. We have some
> customers doing IPSec transport within MPLS VPN for some specific traffic.
> On the other hand, from an SP point of view, when core links are not fully
> trusted, MACSEC or IPSec are also options.
>
> I'm less convinced by the routing that should not be exposed. I agree that
> this is a possibility and a valid use case but I do not think that this is
> a big deal for most of customers (even those requiring more security). The
> good thing of MPLS VPN is the routing complexity is almost pushed to the SP
> and the customer has few things to do and they are happy with that.
>
> The last case of the multitenancy on the customer side is also valid, but
> I also think that it is a niche use case.
>
> My point is that the draft is currently focusing on one scenario which in
> my opinion addresses a niche use case while there may be intermediate
> scenarios (like no multitenancy and/or no need of routing protection) that
> could be more widely applicable.
>
> Brgds,
>
> Stephane
>
>
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Monday, June 11, 2018 21:56
> To: bess@ietf.org
> Subject: [bess] FW: New Version Notification for
> draft-rosen-bess-secure-l3vpn-00.txt
>
> Folks,
>
> Please review and comment on this draft.
>
>   Ron
>
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, June 11, 2018 3:49 PM
> To: Ron Bonica ; Eric Rosen ;
> Eric Rosen 
> Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt
>
>
> A new version of I-D, draft-rosen-bess-secure-l3vpn-00.txt
> has been successfully submitted by Eric C. Rosen and posted to the IETF
> repository.
>
> Name:   draft-rosen-bess-secure-l3vpn
> Revision:   00
> Title:  Augmenting RFC 4364 Technology to Provide Secure Layer
> L3VPNs over Public Infrastructure
> Document date:  2018-06-11
> Group:  Individual Submission
> Pages:  19
> URL: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00
>
> Status: https://datatracker.ietf.org/doc/draft-rosen-bess-secure-
> l3vpn/
> Htmlized:  https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00
>
> Htmlized:  

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[Robert Raszuk]

Jim & Avinash,

Please let's observe that Adrian removed any references to Segment Routing.
What this means that the current proposal is based on vanilla MPLS labels
which by base MPLS architecture have **local significance*. *

You can't assume that out of the sudden label has domain wide or global
meaning with SR references removed any more.

If so this draft in question is not required to dynamically signal a label
bound by operator to given service in a control plane. Just like you
advertise any other label which has local meaning by the node advertising
it. As we pointed out draft-ietf-bess-service-chaining-04 is one option to
signal this. They may be other options, but you either treat label as local
or as domain wide. You can't pretend that under the umbrella of doing
former you are effectively doing latter without admitting it.

Best,
Robert.


On Tue, Mar 20, 2018 at 12:29 PM, UTTARO, JAMES  wrote:

> *I guess I am not being clear.*
>
>
>
> *The issue as I see it is that I do not require NSH to realize the
> creation of simple chains. I simply need SR to realize the chain. Why is
> the IETF forcing me to adopt technology that I do not need, while at the
> same time reducing the number of vendors that I may use in my network as
> this encap will have to be supported by traditional OEMs and others looking
> to get into the business.*
>
>
>
> *TBC I am not against NSH it addresses use cases where dynamic complex
> chains are required. The reality of my world is that I have lots of simpler
> chains i.e FW, LB  and do not need the additional OPEX and CAPEX  costs
> associated with deploying NSH. *
>
>
>
> *Jim Uttaro*
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Robert Raszuk]

Adrian,

> draft-farrel-mpls-sfc provides another transition tool on the migration
to RFC 8300.

Very honestly to me it looks like a road block to faster adoption of NSH
not as help to migrate to RFC 8300 in any way.

> It allows SFFs to be built as a minor mod to existing routers before
there is forwarding plane support for the NSH.

I don't agree with that. "MPLS support" in today's equipment is basic three
label operations IMPOSE, POP & SWAP. I don't see how hardware which can
support those three mechanisms can effectively play any role in what one
would expect from NSH alternative.

And as I mentioned before there is no such a thing like MPLS *only*
networks. One company tried to build MPLS only (without IP forwarding)
router but they dropped that plan. So basic IP can carry NSH front ended
packet to whichever device can process NSH headers.

Adding equivalent processing of now both NSH and MPLS headers (far from
basic pop,swap, impose) operations does not seems like a useful standards
and technology investment at this point.

Best,
Robert.







On Sun, Mar 18, 2018 at 11:10 AM, Adrian Farrel <adr...@olddog.co.uk> wrote:

> Wim and Robert,
>
>
>
> [Dropping SPRING at this point as (as previously discussed) we have taken
> / are taking SR out of this document]
>
>
>
> I think that draft-ietf-bess-service-chaining is really important work:
> it expresses a technique that is implemented and shipping.
>
>
>
> On the other hand, this approach is not fully consistent with RFC 7665.
>
>
>
> But it does describe an actual SFC technology. Whether it remains in the
> field or is a migration technology only time (and operators) will tell.
>
>
>
> Now, if we want to support RFC 7665 and RFC 8300 and use a control plane
> to discover the SFFs and to which SFs they provide access and to install
> "forwarding state" for SFPs, then we also have draft-ietf-bess-nsh-bgp-
> control-plane.
>
>
>
> That draft was originally written with RFC 8300 in mind, but with the
> addition of one sub-TLV to indicate the encoding, it also supports draft-
> farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc
> attempts to model RFC 8300 as much as possible.
>
>
>
> And that brings us back to "Where do we end up, what transition tools
> should we have, and how many steps to transition are there?"
>
>
>
> draft-farrel-mpls-sfc provides another transition tool on the migration
> to RFC 8300. It allows SFFs to be built as a minor mod to existing routers
> before there is forwarding plane support for the NSH.
>
>
>
> But I want to reiterate that the discussion of wat encoding the SF
> supports is a red herring (certainly in the context of RFC 7665). An SF is
> either "SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support
> the SFC encoding (such as NSH) or it can't. But also, an SF is either
> locally attached to the SFF or not. A local attachment is (of course)
> easier to operate and allows "bump in the wire" proxies very easily. A
> remote attached SF is (IMHO) attached via a tunnel.
>
>
>
> The question of "remotely attached SFs" is one that should concern all
> implementations of RFC 7665 because no one (as yet) has worked on a
> protocol to bind SFs to SFFs. Robert is right that providing bump in the
> wire proxy for remotely attached SFs means that it is hard to know/control
> what goes where. But that problem exists to some extent for any remotely
> attached SF. For that reason (among others) I would implement the proxy as
> part of the SFF.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderickx@nokia.
> com]
> *Sent:* 18 March 2018 07:26
> *To:* Robert Raszuk; Adrian Farrel
> *Cc:* mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
>
> *Subject:* Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
>
>
>
> Indeed, this is exactly my point. If you want an interim solution you want
> to use what we have and draft-ietf-bess-service-chaining-04 is an example
> of how you can use the existing data-plane for service chaining.
> draft-farrel-mpls-sfc requires an implementation change in the data-plane,
> whether we like it or not and an upgrade is required even in brownfield
> deployments. So, you better go directly to the final solution defined in
> IETF SFC WG. If we standardize draft-farrel-mpls-sfc we end up supporting
> both forever.
>
>
>
> *From: *<rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
> *Date: *Saturday, 17 March 2018 at 19:13
> *To: *Adrian Farrel <adr...@olddog.co.uk>
> *Cc: *"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.he

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Robert Raszuk]

Hi Adrian,

> That proxy may be a bump in the wire between the SFF and SF

I am not so sure about that ... If this would be just "bump in the wire"
you would have zero guarantees that all packets which need to go via given
function will actually hit that bump - so this is far from a reliable
network service.

There must be associated control plane component attracting traffic to such
bump.

That mechanism with basic MPLS (where labels by based MPLS architecture are
of local significance) is available with L3VPN extensions as already
progressing in BESS (draft-ietf-bess-service-chaining-04) so why not use
this for as you state "interim" ?

No one really addressed that question yet and I think it is a critical one
to make any further judgement  as to the future of this individual
submission.

Cheers,
R.



On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel  wrote:

> Hi Wim,
>
> Thanks for reading the draft so carefully.
>
> > Adrian, on replacement of NSH. You will have to change the SF with this
> proposal
> > in Non proxy case so this proposal does not solve a brownfield case.
> Which SF(s)
> > support MPLS?
>
> This is not about "replacing" the NSH. As you'll see from point 2, below,
> this is about providing an interim / migration technology.
>
> Clearly (and I think you agree) in the case where an SF is not SFC-aware,
> a proxy must be used. That proxy may be a bump in the wire between the SFF
> and SF, a module of the SFF, or a module of the SF. In the case of PNFs,
> only the first two options are available. In the case of a VNF, all three
> options exist.
>
> Now, let us recall where we are starting from. There are PNFs and there
> are VNFs built to look like PNFs. These SFs do not support MPLS or NSH.
>
> Similarly, there are routers that do not support the NSH.
>
> Now, of course, we would all love to sell major upgrades so that every
> component of the network is SFC-aware. But we would also like to start
> deploying SFC into existing network infrastructure.
>
> So your question misses the point. The question to ask is which brownfield
> routers and SFs support NSH?
>
> Cheers,
> Adrian
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03

[Robert Raszuk]

Hi Eric,

Being routable is not the same as having per VRF or per CE unique IPv6
address. Being routable to me means that lookup on first N bits of the
address will result in forwarding action while the last N bits of the
address can have local significance.

The use of "dual purpose" is indeed a bit confusing in the draft however it
is only MAY which one can also read as MAY NOT :) If operator wishes to
have per VRF IPv6 SID implementation complaint with the draft allows that.
However smart implementation may also provide mechanism not to require to
have full IPv6 address per VRF or per CE.

Cheers,
R.


On Tue, Jan 2, 2018 at 3:10 PM, Eric C Rosen <ero...@juniper.net> wrote:

> On 12/28/2017 1:55 PM, Robert Raszuk wrote:
>
> Ok let's start all over :)
>
>
> From the draft:
>
> The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
>   serves the dual purpose of providing reachability between ingress-PE
>   and egress-PE while also encoding the VPN identifier.
>
> I took this to mean that  a single IPv6 address could cause the backbone
> to forward the packet to the egress-PE and cause the egress-PE to look up
> the payload's IP address in a VRF which is identified by that same IPv6
> address.  Did I misunderstand that?
>
>  This suggests that an IPv6 address has to be assigned to each VRF (for
>>  per-VRF "labeling"), or even to each CE (for per-CE labeling).
>>
>
> ​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 SID
> which when appended to IPv6 prefix forms a complete SRv6 SID. Semantics
> does matter here. ​
>
>
> Given the above quote from the draft, I'm not sure what is wrong with what
> I said.
>
>
>  If those addresses are routable, doesn't this create a security issue
>>  as discussed in RFC 4023 Section 8.2?
>>
>
> ​PE's loopback address say /64 being routable causes any security risk ? ​
>
>
> Please see the reference.
>
>
>  The phrase "only has local significance" suggests that these SIDs are
>>  not routable. But later on there is a suggestion that they are
>>  routable, or at least that they might be.
>>
>
> ​Again SIDs are not routable and they have only local significance - true.
> ​They are prepended to say loopback address to form IPv6 SID.
>
>  So there are a number of options:
>>  - not routable
>>  - globally routable
>>  - routable only within egress AS
>>
>
> ​This is referring to routability of SID ... not right. SID does not need
> to be routable. What prefix they are part of may be routable. ​​
>
>
> Just replace my use of the term "SID" with the longer term "the IPv6
> address of which the SID is a part".
>
>
>
>>and the BGP ingress device receiving this route
>>MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
>>the value of the SID to include in the SRH encapsulation.  For L3VPN,
>>only a single SRv6-VPN SID MAY be necessary.
>>
>>  I don't understand the phrase "only a single SRv6-VPN SID MAY be
>>  necessary".
>>
>
> ​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​
>
>
> Still don't understand what is being said.
>
>
>
>If the BGP speaker supports MPLS based
>>L3VPN simultaneously, it MAY also populate the Label values in L3VPN
>>route types and allow the BGP ingress device to decide which
>>encapsulation to use.  If the BGP speaker does not support MPLS based
>>L3VPN services the MPLS Labels in L3VPN route types MUST be set to
>>IMPLICIT-NULL.
>>
>>  Please provide a reference that specifies how you set the Label field
>>  of a SAFI-4 or SAFI-128 route to "implicit null".  I don't recall any
>>  such thing existing in RFC 3107, 4364, or 8277.
>>
>
>
> ​4364 does not restrict what value of VPN label is used - does it ? I
> think this draft now right here defines ​how to read implicit-null being
> placed there :) It's not my idea though - so I will let real inventors to
> comment on it more.
>
>
>>  If you mean "set to three" (the value defined in RFC 3032 to
>> represent
>>  "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
>>  generally interpret the value three in that manner.
>>
>
> ​As mentioned I think it just is being defined here and now. ​
>
>
> I didn't see any mention of the numeric value to put in the label field of
> the NLRI.
>
> or to define a new special or reserved label ​for that embedded signalling.
>
>
&

Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03

[Robert Raszuk]

Ok let's start all over :)

 This suggests that an IPv6 address has to be assigned to each VRF (for
>  per-VRF "labeling"), or even to each CE (for per-CE labeling).
>

​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 SID
which when appended to IPv6 prefix forms a complete SRv6 SID. Semantics
does matter here. ​

 If those addresses are routable, doesn't this create a security issue
>  as discussed in RFC 4023 Section 8.2?
>

​PE's loopback address say /64 being routable causes any security risk ? ​

 The phrase "only has local significance" suggests that these SIDs are
>  not routable. But later on there is a suggestion that they are
>  routable, or at least that they might be.
>

​Again SIDs are not routable and they have only local significance - true.
​They are prepended to say loopback address to form IPv6 SID.

 So there are a number of options:
>  - not routable
>  - globally routable
>  - routable only within egress AS
>

​This is referring to routability of SID ... not right. SID does not need
to be routable. What prefix they are part of may be routable. ​​


>and the BGP ingress device receiving this route
>MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
>the value of the SID to include in the SRH encapsulation.  For L3VPN,
>only a single SRv6-VPN SID MAY be necessary.
>
>  I don't understand the phrase "only a single SRv6-VPN SID MAY be
>  necessary".
>

​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​


   If the BGP speaker supports MPLS based
>L3VPN simultaneously, it MAY also populate the Label values in L3VPN
>route types and allow the BGP ingress device to decide which
>encapsulation to use.  If the BGP speaker does not support MPLS based
>L3VPN services the MPLS Labels in L3VPN route types MUST be set to
>IMPLICIT-NULL.
>
>  Please provide a reference that specifies how you set the Label field
>  of a SAFI-4 or SAFI-128 route to "implicit null".  I don't recall any
>  such thing existing in RFC 3107, 4364, or 8277.
>


​4364 does not restrict what value of VPN label is used - does it ? I think
this draft now right here defines ​how to read implicit-null being placed
there :) It's not my idea though - so I will let real inventors to comment
on it more.


>  If you mean "set to three" (the value defined in RFC 3032 to represent
>  "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
>  generally interpret the value three in that manner.
>

​As mentioned I think it just is being defined here and now. ​


>  I'm not really sure what you're trying to do here. There are at least
>  four cases to consider:
>
>  1. For the case where the backbone doesn't have MPLS, there is no harm
>  in saying "set the label to zero".
>

​Really ? ​What does the backbone having or not having MPLS has to do with
this ? Underlay forwarding does not matter and this is what I read as
"backbone".


 2. For the case where the backbone supports both MPLS and SRv6, and
>  some PEs support L3VPN both ways, while others support only MPLS-based
>  L3VPN, then a real label needs to be put in.
>

​OK.​


>  3. For the case where the backbone supports both MPLS and SRv6, but a
>  particular egress PE only supports SRv6, there needs to be some way to
>  instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
>  presence of the prefix-SID attribute with VPN-SID TLV is sufficient.
>

​Perhaps not ... and this is exactly ​the case trying to be addressed.

 4. For the case where the backbone supports both MPLS and SRv6, the
>  egress PE supports both for transit, but the egress PE only supports
>  SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a
>

​Label in SAFI 1 ? ​




>  value that will cause the egress PE to discard the packet.  If there
>  happens to be an ingress PE that only supports the MPLS style of
> L3VPN,
>  this will prevent the egress PE from misrouting MPLS packets that
>  arrive from that ingress PE.  (This would be an odd, probably
>  transitional, deployment.  But the draft isn't very explicit about
> just
>  what combinations of MPLS and SRv6 it is supposed to support.)
>
>  In any event, the draft would be better off specifying the actual
> label value
>  to be included rather than saying "implicit null". This occurs several
>  times in the draft.
>

​.. or to define a new special or reserved label ​for that embedded
signalling.

Kind regards,
R.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Point #3 on draft-ietf-grow-bgp-reject

[Robert Raszuk]

Sorry one typo:

s/to make all receive routes ineligible for best path/to make all receive
routes eligible for best path/

Apologies,
r.


On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk <rob...@raszuk.net> wrote:

> Dear IDR and BESS WGs members,
>
> As you have either participated or seen from other email exchanges there
> is ongoing communication about change in eBGP specification to mandate by
> default use of policy in order to make all receive routes ineligible for
> best path and to suppress sending them to your peers. And that in spite of
> different opinions of the authors itself at this point is to apply to all
> existing and future AFI/SAFIs.
>
> John S. summarized this point as stated below:
>
>
>
>
> *"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
> apply only to Internet routing and not other applications?Pro: the
> motivation section of the document calls out the Internet use caseCon:
> there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1
> can be used in a VPN context, e.g.). different defaults for different
> AFI/SAFI is confusing for the user and the extra complexity not required."*
>
> So first let me observe that technically it is very clear to know that
> under vrf in a VPN context (towards CEs or inter-as ASBR in option A)
> address family ipv4 or ipv6 unicast is configured. There is no disambiguity
> of it of any sort. Likewise it is also very clear when address family vpnv4
> or vpnv6 is configured over eBGP Inter-AS option B or C sessions.
>
> During IDR discussion 4 individual contributors where opposed to make this
> proposal applicable to any eBGP AFI/SAFI and recommended to make it only
> for IPv4 and IPv6 existing address families. While in the same time only
> voice of 1 with reference to past discussion in GROW WG had taken place
> expressed otherwise. Well this reference to GROW list in 2016 results in
> one voice against, one pro and author concluding that this is pro all AFs.
>
> I think on that point if there is rough consensus at all it is really
> against that.
>
> Now why I am bringing this specific point up ...
>
> * There are numerous SAFIs in use today that even authors of this proposal
> fail to produce any valid in or out policy other then "send all/accept
> all". So even with good will operator will be simply forced to add those
> lines to the configuration. Now fun starts when an implementation code does
> not allow for it in some specific AFI/SAFIs or that manual policy would
> overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that
> to be complaint to this proposal implementations must change.
>
> * This draft is to update RFC4271 that means that now any newly defined
> AFI/SAFI will also have to define a set of policies to be used to enable it
> over eBGP sessions both in the draft/rfc and in the code. That clearly
> makes it harder for everyone with no gain.
>
> * There are address families today which are opaque to best path and are
> applied when received .. examples BGP-LS or Flow-spec. At most best path is
> run only when sending it out (if at all). The current spec does not limit
> reception of the information but does limit its eligibility for best path
> computation. I think there is room for large number of surprising
> behaviors with that for those SAFIs which carry opaque information to core
> BGP.
>
> * As the spec (as it is written today) applies to all eBGP sessions what
> happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at
> all and does not carry "routes" ? Would it be explicitly allowed ?
> (Example: draft-ietf-idr-operational-message-00).
>
> *  As the spec (as it is written today) applies to all "routes" received
> or to be sent over eBGP sessions it actually fails to define what is a
> "route" Within MP_REACH we have a concept of NLRI which for different
> address families have been redefined and departed long time back from pure
> definition of ip route.
>
> * If BGP UPDATE message carries only MP_UNREACH attribute .. so
> effectively routes to be withdrawn .. are those still subject to proposed
> policy or not ?
>
>
> Therefor I would like to ask members of both working groups to express
> clear opinion if this proposal and update to RFC4271 specification should
> apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended
> to all AFI/SAFIs we have today and we are going to invent in the future.
>
> If the majority of WG members would choose to have this change applicable
> to all AFI/SAFIs I do ask authors to address in the document all of the
> above points before proceeding forward.
>
> Kind regards,
> Robert.
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Point #3 on draft-ietf-grow-bgp-reject

[Robert Raszuk]

Dear IDR and BESS WGs members,

As you have either participated or seen from other email exchanges there is
ongoing communication about change in eBGP specification to mandate by
default use of policy in order to make all receive routes ineligible for
best path and to suppress sending them to your peers. And that in spite of
different opinions of the authors itself at this point is to apply to all
existing and future AFI/SAFIs.

John S. summarized this point as stated below:




*"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
apply only to Internet routing and not other applications?Pro: the
motivation section of the document calls out the Internet use caseCon:
there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1
can be used in a VPN context, e.g.). different defaults for different
AFI/SAFI is confusing for the user and the extra complexity not required."*

So first let me observe that technically it is very clear to know that
under vrf in a VPN context (towards CEs or inter-as ASBR in option A)
address family ipv4 or ipv6 unicast is configured. There is no disambiguity
of it of any sort. Likewise it is also very clear when address family vpnv4
or vpnv6 is configured over eBGP Inter-AS option B or C sessions.

During IDR discussion 4 individual contributors where opposed to make this
proposal applicable to any eBGP AFI/SAFI and recommended to make it only
for IPv4 and IPv6 existing address families. While in the same time only
voice of 1 with reference to past discussion in GROW WG had taken place
expressed otherwise. Well this reference to GROW list in 2016 results in
one voice against, one pro and author concluding that this is pro all AFs.

I think on that point if there is rough consensus at all it is really
against that.

Now why I am bringing this specific point up ...

* There are numerous SAFIs in use today that even authors of this proposal
fail to produce any valid in or out policy other then "send all/accept
all". So even with good will operator will be simply forced to add those
lines to the configuration. Now fun starts when an implementation code does
not allow for it in some specific AFI/SAFIs or that manual policy would
overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that
to be complaint to this proposal implementations must change.

* This draft is to update RFC4271 that means that now any newly defined
AFI/SAFI will also have to define a set of policies to be used to enable it
over eBGP sessions both in the draft/rfc and in the code. That clearly
makes it harder for everyone with no gain.

* There are address families today which are opaque to best path and are
applied when received .. examples BGP-LS or Flow-spec. At most best path is
run only when sending it out (if at all). The current spec does not limit
reception of the information but does limit its eligibility for best path
computation. I think there is room for large number of surprising
behaviors with that for those SAFIs which carry opaque information to core
BGP.

* As the spec (as it is written today) applies to all eBGP sessions what
happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at
all and does not carry "routes" ? Would it be explicitly allowed ?
(Example: draft-ietf-idr-operational-message-00).

*  As the spec (as it is written today) applies to all "routes" received or
to be sent over eBGP sessions it actually fails to define what is a "route"
Within MP_REACH we have a concept of NLRI which for different address
families have been redefined and departed long time back from pure
definition of ip route.

* If BGP UPDATE message carries only MP_UNREACH attribute .. so effectively
routes to be withdrawn .. are those still subject to proposed policy or not
?


Therefor I would like to ask members of both working groups to express
clear opinion if this proposal and update to RFC4271 specification should
apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended
to all AFI/SAFIs we have today and we are going to invent in the future.

If the majority of WG members would choose to have this change applicable
to all AFI/SAFIs I do ask authors to address in the document all of the
above points before proceeding forward.

Kind regards,
Robert.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Robert Raszuk]

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.

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.

Cheers,
Robert.

REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] IDR heads up on BESS draft: BGP for SFC: draft-mackie-bess-nsh-bgp-control-plane-04.txt

[Robert Raszuk]

Hi,

Using BGP as control plane for arbitrary service topology creation is by
all means a good thing.

That is why in 2013 Keyur and myself have posted proposal describing it to
IETF in form of BGP Vector Routing:

https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00

I leave it to the audience of bess and idr working groups to jugde which of
two proposals is more elegant and low risk and effort.

Cheers,
R.


On Feb 16, 2017 7:17 PM, "Tony Przygienda"  wrote:

Discounted for same affiliation with the authors  I do think personally
it's a symmetrical, quite elegant and low risk/effort draft given how
successful equivalent BGP "low level network service access point"
synchronization proposals were over last years ...



Sent from myMail for iOS


Thursday, February 16, 2017, 13:25 -0800 from Adrian Farrel <
adr...@olddog.co.uk>:

Hi IDR,

We have an I-D in BESS (also discussed in SFC) that proposes to use BGP as a
control plane for and SFC (overlay) network.

You can best grasp the proposed extensions to BGP by looking at the I-D. We
think the extensions are natural and relatively small, by YMMV :-)

Completely understanding what we are planning may be hard without some
background in service function chaining, but from 30,000 ft...

An SFC network is an overlay network.
Service Function Forwarders (SFFs) are connected by tunnels over one or more
underlay networks.
SFFs provide access to Service Function Instances (SFIs)
SFIs are strung together in an ordered sequence called a Service Function
Path
(SFP) [an instance of a Service Function Chain (SFC)]
It used to be that service functions were installed as physical bumps in the
wire, but now they may be remote and virtualized.
Packets that need to be acted on by a series of service functions (an SFC)
are
classified by a Classifier and assigned to an SFP.
The packets are marked (with an additional encapsulation header) and passed
from
SFF to SFF for delivery to the SFIs.

Our approach uses BGP so that:
- SFFs can advertise which SFIs they provide access to so that a controller
can
build SFPs
- a controller to advertise the various SFPs so that SFFs can work out how
to
deliver
   packets to the right SFIs, and how to route packets to the correct next
SFF
- a controller to instruct a Classifier on how to select the right SFP

We also help the SFF know what tunnel to use to reach the next SFF, and
what SFC
encapsulation to use on each hop.

For more details, read the draft :-)

Discussions should probably be on the BESS list, but we will probably also
spot
them if they happen here.

Thanks,
Adrian

___
Idr mailing list
i...@ietf.org 
https://www.ietf.org/mailman/listinfo/idr


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

Re: [bess] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

​Acee,​


> The current capability is specific to support of multiple labels - not
> your parochial view on the interaction between SAFIs.
>

​Since "bis" specification obsoletes the base document I was under the
assumption that new capability will also obsolete the current used.

It is no longer "3107bis" but just a new draft or at best errata -  to the
best of my understanding of IETF rules "bis" obsoletes the original spec.
Requiring implmentors to read and follow both specifications to correctly
implement the labeled BGP AF seems a bit odd ... don't you think ?

 Are you suggesting a second capability? All the more reason for a separate
> draft.
>

​No.​ See above.

In any event, the non-backward compatible behavior you are proposing would
> be better served in a separate draft than to burden RFC 3107 BIS.
>

​Section 5 already discusses that point - so my comment should be
considered as feedback towards that section . If there is WG consensus to
proceed with that it would be pure waist of time to write a separate draft
to argue against it.

It seems interesting that IETF WG feedback expressed on the list for
specific section of the draft in adoption call or during WG progress is
turned around and request is made to write a new draft instead.

Especially that document wise the feedback consideration may require
addition of two sentences within section 5 :).

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

Re: [bess] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

Hi Acee,

There is no issue for compatibility as new proposal has its new BGP
capability hence there is no issue with deploying it gradually.

Yes it requires new RIB work for those implementations which today use
single RIB for both SAFI 1 and SAFI 4. FIB and LFIB are already separate.
Each SAFI in BGP also normally has it's own separate tables. So if anything
it requires a bit of cleanup work.

Main motivation here would be to help new vendors to make the unified
choice in how they will implement 3107bis so long term we get some
consistent way SAFI 4 is delivered. And if now at the "bis" rfc is not a
good time then what you are really advocating is to stay for years to come
with such undefined randomness across implementations.

Other then consistency I also see folks trying to use labeled BGP as
controller to network device protocol to install labels. For that use case
alone complete separation from SAFI 1 is very helpful.

Thx,
R.



On Wed, Aug 31, 2016 at 4:15 PM, Acee Lindem (acee) <a...@cisco.com> wrote:

> Hi Robert,
>
> Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much
> backward compatible with our more than a decade old RFC 3107
> implementations and deployments. What you are proposing is not and has
> implications in both the control and forwarding planes. If you really
> believe that this is “the biggest issue", I’d suggest you articulate it in
> a separate draft with concrete use cases for having separate IP and MPLS
> topologies for the same set of prefixes. Then the WGs can evaluate the
> requirement and proposed solution independent of RFC 3107 BIS.
>
> Thanks,
> Acee
>
> From: mpls <mpls-boun...@ietf.org> on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Wednesday, August 31, 2016 at 5:24 AM
> To: Eric C Rosen <ero...@juniper.net>
> Cc: IDR List <i...@ietf.org>, "m...@ietf.org" <m...@ietf.org>, "
> bess@ietf.org" <bess@ietf.org>
> Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on
> draft-rosen-mpls-rfc3107bis
>
> Hi Eric,
>
> While adoption call is sort of encouragement for further input before I
> respond to Loa's mail I would like to get one additional answer from
> 3107bis authors and WGs members.
>
> Those who spend years in mpls deployment know quite well that the biggest
> issue with today's 3107 deployment is lack of the clear definition of its
> interaction with SAFI-1. While one would hope that 3107bis with new
> capability will clean this mess section 5 of your document rather sweeps it
> all under the carpet stating that it is just local policy. IMO it is not a
> matter of local policy nor it is implementation detail.
>
> Local policy can be to choose which RIB (or sequence of RIBs) should be
> used for resolution of specific SAFIs and not how to mix SAFI-1 with
> SAFI-4. It's not a local matter at all to have deployment resulting in
> inconsistent IBGP best paths across given domain.
>
> To me cleanest is to separate those two SAFIs completely from each other
> by the spec both in BGP (done) as well as local RIB and FIB/LFIB.
>
> Likewise I do not quite agree that SAFI-4 should be "convertible" to
> SAFI-1. And we all realize that opposite direction is rather hard.
>
> Another perhaps minor clarification would be to get an explicit
> confirmation that SAFI-4 can be recursive over SAFI-4 or for that matter
> SAFI-1 (MPLS in GRE or SR in IP).
>
> Thx,
> R.
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

Hi Eric,

While adoption call is sort of encouragement for further input before I
respond to Loa's mail I would like to get one additional answer from
3107bis authors and WGs members.

Those who spend years in mpls deployment know quite well that the biggest
issue with today's 3107 deployment is lack of the clear definition of its
interaction with SAFI-1. While one would hope that 3107bis with new
capability will clean this mess section 5 of your document rather sweeps it
all under the carpet stating that it is just local policy. IMO it is not a
matter of local policy nor it is implementation detail.

Local policy can be to choose which RIB (or sequence of RIBs) should be
used for resolution of specific SAFIs and not how to mix SAFI-1 with
SAFI-4. It's not a local matter at all to have deployment resulting in
inconsistent IBGP best paths across given domain.

To me cleanest is to separate those two SAFIs completely from each other by
the spec both in BGP (done) as well as local RIB and FIB/LFIB.

Likewise I do not quite agree that SAFI-4 should be "convertible" to
SAFI-1. And we all realize that opposite direction is rather hard.

Another perhaps minor clarification would be to get an explicit
confirmation that SAFI-4 can be recursive over SAFI-4 or for that matter
SAFI-1 (MPLS in GRE or SR in IP).

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

Re: [bess] [Idr] draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

Hi AC,

I am much less concern if we must be stuck to 3107 till retirement.

I think it would be much smoother on many levels to leave 3107 as is and
propose better solution for interdomain label exchange with BGP in new RFC.

With time we can obsolete 3107.

Such model has been done in the past and worked pretty well AFAIK.

Best,
r.



On Fri, Apr 1, 2016 at 11:29 PM, Acee Lindem (acee) <a...@cisco.com> wrote:

> Hi Robert,
>
> I think this would defeat the purpose of clarifying RFC 3101 multi-label
> behavior in a BIS draft. Let’s see if we can reach consensus first.
>
> Thanks,
> Acee
>
> From: Idr <idr-boun...@ietf.org> on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Friday, April 1, 2016 at 4:23 PM
> To: Eric C Rosen <ero...@juniper.net>
> Cc: Bruno Decraene <bruno.decra...@orange.com>, "m...@ietf.org" <
> m...@ietf.org>, BESS <bess@ietf.org>, IDR List <i...@ietf.org>
> Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis
>
> Hi Eric,
>
> I have read your proposed draft as well as watched this thread with a bit
> of an interest.
>
> To me the best compromise - which is to agree with Bruno's points as well
> as address your intentions is simply to request new SAFI for 3107bis.
>
> From the draft you are really not updating 3107 base spec but obsoleting
> it which to me looks like a bad idea.
>
> You are even requesting to remove IANA reference to original spec. How
> would IANA know when is it safe to do that .. meaning when all
> implementations will not suddenly support and all deployments will enable
> 3107bis ?
>
> New SAFI requires a new capability which you are asking for anyway.
>
> As far as implementations please keep in mind very important point that
> some implementations treat SAFI 1 & 4 in single table and some in separate
> tables. That when mixed with 3107bis may just explode if not in new set of
> bugs then with operational nightmare. While we are at this it would be much
> cleaner to mandate in the new spec to have 3107bis always to use separate
> tables as compared with from SAFI 1.
>
> Thx,
> Robert.
>
> PS.
>
> As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
> well stated that this is only one deployment option for interdomain
> encapsulation. I would very much like to see a section indicating that IPv6
> or/and IPv4 be used as an alternative encap for those applications which
> require it and when needed provide local bindings between intradomain MPLS
> and interdomain IP.
>
>
> On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen <ero...@juniper.net> wrote:
>
>> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
>>
>>> I'm quite sure you have deployed  implementations, from several
>>>> prominent vendors, that will not properly handle this case.
>>>>
>>> I'm waiting for this/these implementation(s) to make a public statement
>>> in this thread / IETF WGs. Then we can discuss whether the issue comes from
>>> RFCF3107 or from the implementation.
>>> If none make a public statement, we should assume that all
>>> implementations are capable of receiving multiple labels, as per RFC 3107.
>>>
>> I strongly disagree with this.  We should not ignore the facts just
>> because you don't like the way the facts were gathered.
>>
>> A better approach would be to have operators state whether they have any
>> deployments in which the "multiple labels" feature is used in a
>> multi-vendor environment.  It is very useful when working on a "bis" draft
>> to determine which features have been proven to work in a multi-vendor
>> environment and which have not.
>>
>> Any non-compliant implementation may create interoperability issues and
>>> unpredictable results.
>>>  From an IETF standpoint, the question is whether a RFC 3107
>>> implementation would create interoperability issues, up to shutting down
>>> the BGP session.
>>>
>>
>> There are deployed 3107 implementations which always assume that the NLRI
>> contains a single label.  If you tried to interwork these with 3107
>> implementations that send multiple labels , you will experience the kind of
>> disruption.  3107bis tries to allow the use of multiple labels while
>> preventing this sort of disruption from occurring.
>>
>> If you mean that some non-compliant implementation do not work, well
>>> let's fix them.
>>>
>>
>> The situation is that there is a commonly deployed "bug" in old
>> implementations, but it is not seen because the bug is in a feature

Re: [bess] draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit
of an interest.

To me the best compromise - which is to agree with Bruno's points as well
as address your intentions is simply to request new SAFI for 3107bis.

>From the draft you are really not updating 3107 base spec but obsoleting it
which to me looks like a bad idea.

You are even requesting to remove IANA reference to original spec. How
would IANA know when is it safe to do that .. meaning when all
implementations will not suddenly support and all deployments will enable
3107bis ?

New SAFI requires a new capability which you are asking for anyway.

As far as implementations please keep in mind very important point that
some implementations treat SAFI 1 & 4 in single table and some in separate
tables. That when mixed with 3107bis may just explode if not in new set of
bugs then with operational nightmare. While we are at this it would be much
cleaner to mandate in the new spec to have 3107bis always to use separate
tables as compared with from SAFI 1.

Thx,
Robert.

PS.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
well stated that this is only one deployment option for interdomain
encapsulation. I would very much like to see a section indicating that IPv6
or/and IPv4 be used as an alternative encap for those applications which
require it and when needed provide local bindings between intradomain MPLS
and interdomain IP.


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen  wrote:

> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
>
>> I'm quite sure you have deployed  implementations, from several
>>> prominent vendors, that will not properly handle this case.
>>>
>> I'm waiting for this/these implementation(s) to make a public statement
>> in this thread / IETF WGs. Then we can discuss whether the issue comes from
>> RFCF3107 or from the implementation.
>> If none make a public statement, we should assume that all
>> implementations are capable of receiving multiple labels, as per RFC 3107.
>>
> I strongly disagree with this.  We should not ignore the facts just
> because you don't like the way the facts were gathered.
>
> A better approach would be to have operators state whether they have any
> deployments in which the "multiple labels" feature is used in a
> multi-vendor environment.  It is very useful when working on a "bis" draft
> to determine which features have been proven to work in a multi-vendor
> environment and which have not.
>
> Any non-compliant implementation may create interoperability issues and
>> unpredictable results.
>>  From an IETF standpoint, the question is whether a RFC 3107
>> implementation would create interoperability issues, up to shutting down
>> the BGP session.
>>
>
> There are deployed 3107 implementations which always assume that the NLRI
> contains a single label.  If you tried to interwork these with 3107
> implementations that send multiple labels , you will experience the kind of
> disruption.  3107bis tries to allow the use of multiple labels while
> preventing this sort of disruption from occurring.
>
> If you mean that some non-compliant implementation do not work, well let's
>> fix them.
>>
>
> The situation is that there is a commonly deployed "bug" in old
> implementations, but it is not seen because the bug is in a feature that no
> one has been using.  If new implementations use that feature, the bug will
> be seen, and network disruption will occur. One could say "fix all the old
> implementations", but it seems wiser to have new implementations avoid
> tickling the bug.   The Capability is not proposed  for the purpose of
> helping the vendors, it's there to help the operators.
>
> I'm not sure why you think there would be BGP session drops due to
> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
> implementation, I think the 3107bis implementation would do
> "treat-as-withdraw" rather than "drop the session".
>
> Perhaps a reasonable approach for 3107bis would be the following:
>
> - A 3107bis implementation will not send multiple labels to a peer unless
> the Capability has been received from that peer.  (This prevents 3107bis
> implementations from tickling the 'bug' in 3107 implementations.)
>
> - A 3107bis implementation will accept multiple labels from a peer even in
> the absence of the Capability.
>
> Another approach would be to have a knob that determines whether the
> Capability needs to be used before multiple labels are advertised.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal

[Robert Raszuk]

Hi Thilakarathne,

Point #1:

What makes you think that 10 ms over 1 GB ethernet peering is any better
then 20 ms RTT over 100 GB ? I would really prefer to get routed over 100
GB peerings even if the RTT would be doubled.

Point #2:

 There is no reqirment to synchronize different administrative
 domains since router itself automatically calculate value and
 add when routes  advertised similar to AS PATH addition
 operation.

Sorry to ruin your impression about power and intelligence of routers, but
they only do what they are programmed to do.

So Jim's point about synchronizing metrics is still valid. Of course I
assume that for you the only metric you consider here are milliseconds and
therefor do not bother.

Imagine one operator chooses to use physical distance and other RTT. So in
the new attribute you will get time [ms] vs distance [miles]. Yet one more
will also use distance buy expressed in kilometers. Please elaborate how
useful such comparison will turn out to be ?

Point #3:

As you are suggesting use of ICMP to measure RTT please keep in mind that
ICMP is not high priority protocol. It may wait in the remote or local
router for processing much more then the propagation delay of the link it
arrived on.

Point #4:

How often do you plan to remeasure the eBGP propagation ? Note that today
many optical long haul transmission is hidden from ASBRs. That means that
your provider of long distance connection may at will reroute you via his
own web of fiber which does affect RTT. So it is pretty safe to assume what
you have measured yesterday today is irrelevant.

Point #5:

eBGP propagation may be few orders of magnitude less relevant as
propagation within each AS path is traversing. And except the case of few
ASes under the same administration we do not have a way to express that one
today except AIGP attribute.

So if you would like to continue your research perhaps looking at that
aspect first may be more valuable 

Cheers,
R.


On Sat, Aug 8, 2015 at 7:10 AM, Duleep Thilakarathne dule...@mobitel.lk
wrote:

 Richard,

 Yes I am referring eBGP scenario. I suggest distance calculations based on

 1. ICMP delay between eBGP speakers.
 2. Manually configure  binding to remote AS.


 Each eBGP speaking routers need to accumulate  distance value when
 advertised routes to external peer.There is no reqirment to synchronize
 different administrative domains since router itself automatically
 calculate value and add when routes  advertised similar to AS PATH addition
 operation.





 - Reply message -
 From: Richard Li renwei...@huawei.com
 To: Duleep Thilakarathne dule...@mobitel.lk, UTTARO, JAMES 
 ju1...@att.com, 'Robert Raszuk' rob...@raszuk.net
 Cc: 'bess@ietf.org' bess@ietf.org
 Subject: [bess] BGP route selection criteria - geographic distance when
 AS_PATH are equal
 Date: Fri, Aug 7, 2015 10:11 PM

 There might be a good point here. RFC 7311 only takes care of the IGP
 metrics. But In Duleep’s example, the metrics between two eBGP speakers are
 not taken into consideration. In order to have AIGP attribute to really
 represent the accumulated one, the metrics on such links should be
 considered as well. However, there might be some challenges or obstacles:
 The way to configure one metrics on the link between two eBGP speakers
 might not be consistent with the way to configure another metrics on the
 another link between two speakers.



 Richard



 *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Duleep
 Thilakarathne
 *Sent:* Friday, August 07, 2015 8:41 AM
 *To:* UTTARO, JAMES; 'Robert Raszuk'
 *Cc:* 'bess@ietf.org'
 *Subject:* Re: [bess] BGP route selection criteria - geographic distance
 when AS_PATH are equal



 Jim,





 What I want to suggest is to insert item 5 (refer below items listed) to
 BGP best path selection algorithm. Once AS-PATH length is equal, next we
 can think on how to select best outgoing interface. If we don’t select
 proper outgoing interface it will affect to latency. I am talking this
 based on practical experience I have in ISP environment. There are several
 options to select best outgoing interface when AS-PATH are equal.  In this
 case I suggest geo distance to destination. Following are options to
 calculate geo distance. Router selects outgoing interface with lowest GEO
 distance to destination.



 1. BGP speaking router can add distance when advertise to route to
 upstream similar to AS-PATH attribute. For example



 ABC-D



 Router B advertise distance AB to router C. router C advertise accumulated
 distance AB+BC to router D.



 2. Above distance can be configured as manual interface command or
 dynamically using ICMP or similar mechanism. We can assume ICMP delay
 propositional to geo distance.



 3. Alternative option is to calculate real geo distance from coordinate
 system. In this case we miss intermediate hops. Accuracy is not much
 accurate since cable paths do not follow real coordinate based distance

Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal

[Robert Raszuk]

Hi Duleep,

Please consider RFC 7311 and provide feedback why you think it is not
sufficient for your objective.

https://tools.ietf.org/html/rfc7311

Best,
R.


On Sun, Jul 26, 2015 at 9:15 PM, Duleep Thilakarathne dule...@mobitel.lk
wrote:

  Hi,



 I would like to suggest to consider geographic distance when AS_PATH  are
 equal in BGP route selection criteria. (as tie breaking rule). Can anybody
 comment on my idea.





 Regards

 Duleept







 This e-mail and any attachments may contain confidential and
 privileged information. If you are not the intended recipient,
 please notify the sender immediately by return e-mail, delete this
 e-mail and destroy any copies. Any dissemination or use of this
 information by a person other than the intended recipient is
 unauthorized and may be illegal.
 Mobitel (Pvt) Ltd.

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


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

Re: [bess] ARP ND draft

[Robert Raszuk]

Ok I think there are two scenarios.

The original scenario I had in mind was indeed the loopback anycast which
would really not have any issues with arp.

The other scenario is NIC overload with multiple addresses some of them
would be anycast. It is in fact not that uncommon to have an identical VMs
with same IP for robustness without LB. I am not sure if we need to *solve*
it at ARP, but we do need to consider it as a valid case and not react as
far as duplicate address detection is concerned. Again here depending on
the implementation if you put both such VMs say in different VRFs you have
no ARP issue, but anycast works fine.

I think to proceed I would be happy to see those cases just documented in
deployment section of the draft and we move on. I do not think that solving
or even touching IPv4 ARP is needed here at this point.

Or perhaps a different comment to add to the draft would be to mention that
duplicate IPv4 address detection is scoped to the same ARP table (which may
not be the same as same subnet :).

Cheers,
r.




On Thu, Apr 16, 2015 at 12:44 AM, Erik Nordmark nordm...@acm.org wrote:

 On 4/15/15 2:53 PM, Robert Raszuk wrote:

 Erik,

 How about /32 IPv4 anycast addresses with multiple subnet per linux NIC ?
 It is typical to be able to overload host networking with same anycast
 loopbacks.

 I guess same subnet isn't sufficient as criteria - same subnet which
 corresponds to a connected route would be one way to phrase the constraint.


 It does not need to be ARP resolved .. the resolution is indirect via
 connected next hops.

 Yes, that is the key issue.

 For instance host routes (/32) and an anycast address on a loopback
 interface works fine in IPv4 and IPv6.

Erik


 Cheers,
 R.




 On Wed, Apr 15, 2015 at 11:48 PM, Erik Nordmark nordm...@acm.org
 mailto:nordm...@acm.org wrote:

 On 3/31/15 1:10 PM, Rabadan, Jorge (Jorge) wrote:

 Hi Robert and Tony,

 As Wim mentioned, ipv6 anycast is something that we will add
 to the draft in the next rev. There is an easy way to know if
 a given proxy-ND entry belongs to an anycast address or not
 and disable the duplicate IP detection for those.

 The challenge for IPv4 is that I don’t see an easy way to
 learn _dynamically_ from access attachment circuits that a
 given ipv4 is anycast. Even for default gateways, if they are
 integrated in the EVPN PE, we are good, but if they are
 external and connected to a MAC-VRF, it is not so clear how to
 learn that (unless you learn those entries from the management
 interface).

 Jorge,

 IPv4/ARP doesn't have any support for anycast address on the same
 subnet. While IPv6/ND has such support (using the O-flag) the
 common anycast deployment for both is to have the anycast
 instances deployed on different subnets and, in the case of DNS
 servers, in different ISPs.

 Thus for IPv4 I think you can assume that the same IP address
 appearing with different MAC addresses is either a duplicate IP
 address or a case of a host having changed the MAC address on its
 NIC. (I don't know if NIC bonding can be configured in a way where
 it looks like an IP-MAC change each time there is a failure; if
 so that would be a third case.)

Erik


 One of the reasons why we have lots of “SHOULDs” in the draft
 and not “MUST” is because the implementation has to be
 flexible enough to be configured in a different way depending
 on the use-case, which is one of the points that Tony mentions
 below. In the use-case described at the moment there is no
 anycast and duplicate IP detection is very important. We will
 add the DC use case in the next rev as suggested by Robert and
 others.
 Thanks.
 Jorge


 From: Antoni Przygienda antoni.przygie...@ericsson.com
 mailto:antoni.przygie...@ericsson.com
 mailto:antoni.przygie...@ericsson.com
 mailto:antoni.przygie...@ericsson.com
 Date: Monday, March 30, 2015 at 12:12 AM
 To: Robert Raszuk rob...@raszuk.net
 mailto:rob...@raszuk.net mailto:rob...@raszuk.net
 mailto:rob...@raszuk.net, Henderickx, Wim (Wim)
 wim.henderi...@alcatel-lucent.com
 mailto:wim.henderi...@alcatel-lucent.com
 mailto:wim.henderi...@alcatel-lucent.com
 mailto:wim.henderi...@alcatel-lucent.com
 Cc: Erik Nordmark nordm...@acm.org mailto:nordm...@acm.org
 mailto:nordm...@acm.org mailto:nordm...@acm.org,
 bess@ietf.org mailto:bess@ietf.org mailto:bess@ietf.org
 mailto:bess@ietf.org bess@ietf.org mailto:bess@ietf.org
 mailto:bess@ietf.org mailto:bess@ietf.org, Jorge Rabadan
 jorge.raba...@alcatel-lucent.com
 mailto:jorge.raba...@alcatel-lucent.com
 mailto:jorge.raba...@alcatel-lucent.com

 mailto:jorge.raba

Re: [bess] ARP ND draft

[Robert Raszuk]

Hi Wim,

 There is anycast at IPv4 level for sure but I am not ware this is
supported at arp level.

Precisely right. It needs to be documented and addressed if anyone is up to
proposing automated IP duplicate address detection and disabling.

RFC1546 is rather too old to consider here as solution :)

Cheers,
R.


On Mon, Mar 30, 2015 at 1:10 AM, Henderickx, Wim (Wim) 
wim.henderi...@alcatel-lucent.com wrote:

  To be clear: RFC4861 section 7.2.7 explains the anycast behaviour in
 IPv6.
 I am not aware of such thing at IPv4/ARP level. Do you have a pointer?
 There is anycast at IPv4 level for sure but I am not ware this is
 supported at arp level.

   From: Henderickx, Wim Henderickx
 Date: Monday 30 March 2015 07:38
 To: Robert Raszuk
 Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.org, Jorge Rabadan

 Subject: Re: [bess] ARP ND draft

   At interface level you get dad in most stacks I know.

 Sent from my iPhone

 On 30 Mar 2015, at 06:45, Robert Raszuk rob...@raszuk.net wrote:

Hi Wim,

  What makes you say that in IPv4 there is no anycast ? All anycase I have
 played so far is IPv4 :)

  Cheers,
  r.

 On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) 
 wim.henderi...@alcatel-lucent.com wrote:

 We will update the draft to highlight the IPv6 anycast behaviour better
 as pointed out by RObert. In IPv4 there is no anycast behaviour and as such
 there should be one option possible.



 On 30/03/15 04:59, Antoni Przygienda antoni.przygie...@ericsson.com
 wrote:

 Yes, but of course I brought it up to show that 'the last one simply
 wins' as suggested by the draft is not enough IMO. A good architecture
 should probably keep track of what it served as answer and when the answer
 is invalid or a new, better one exists, provide a GARP.
 
 As well, when PE2 sends a newer MAC it may not be a good strategy to
 serve a GARP if PE1's MAC has already been offered. That could lead IMO to
 e.g. gateway chasing problems.
 
 --- tony
 
 
 There are basically two types of people. People who accomplish things,
 and people who claim to have accomplished things. The first group is less
 crowded.
 ~~~ Mark Twain
 
 
  -Original Message-
  From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
  Sent: Thursday, March 26, 2015 6:01 AM
  To: Antoni Przygienda; Erik Nordmark; Rabadan, Jorge (Jorge)
  Cc: bess@ietf.org
  Subject: Re: [bess] ARP ND draft
 
  For this case you should sent a GARP with the new MAC/IP
 
 
 
 
  On 25/03/15 18:56, Antoni Przygienda antoni.przygie...@ericsson.com
 
  wrote:
 
b)It is worth explaining what is suggested behavior if eVPN
advertises the same IP with multiple MACs and what happens when
e.g. the served MAC vanishes
   
   Doesn't the EVPN RFC already stating that the routes would be
   withdrawn in that case?
  
  The scenario I had in mind was when eVPN PE receives
  
  From PE2  IP1/M1  and  later
  From PE3  IP1/M2
  
  while having answered with IP1/M1 per proxy alrady. Additionally, in
  such situation ends up seeing
  
  From PE2   IP1/no MAC
  
  So the answer it gave is not valid anymore all of a sudden.
  
  --- tony
 ___
 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