[grnog] GRNOG7 sign-off
Yannis Nikolopoulos
yanodd at otenet.gr
Fri Jul 13 13:21:39 CEST 2018
καλησπερα,
a few comments inline
On 07/13/2018 12:15 PM, Tasos Karaliotas wrote:
>
> Hello,
>
> Regarding longer prefix propagation ...an obvious case is this:
>
> As IPv4 space has been exhausted, we in GRNET, tend to assign even
> longer prefixes to our members [aka customers] ( /26,/27...up to /29).
> When multi-homing is desired by the member then the other SP should
> propagate longer prefixes to its upstream in order to service the
> member. In our turn we need to de-aggregate the same long, part of our
> supernet, prefix and advertise it to our upstreams in order to let the
> customer to choose the desired path.
>
+1
> We've exchanged few mails about that in the list, some time ago. Of
> course there are other variations to this scenario.
>
> If you like, we could organize a more detailed discussion about this
> topic during our next GRNOG technical meeting.
>
> Regards
>
> Tasos
>
>
> On 13/07/2018 09:07 πμ, Nikos Leontsinis wrote:
>>
>> Παρακολουθησα την ημεριδα απο τοipad.Χαιρετιζω την προσπαθεια και
>> συγχαρητηρια σε ολουςτους συντελεστες.
>>
>> Ισως οιvendorsθα μπορουσαν να συμμετεχουν και να υπστηριζουν εδω.
>>
>> A few comments about the security discussion:
>>
>> Let’s just say rfc 7454 is a good place to start.
>>
>> 1. /The RIPE community has documented that:IPv4prefixes longer than
>> /24 and IPv6 prefixes longer than /48 are/
>>
>> /generally neither announced nor accepted in the Internet/and there
>> is a best practice rfc supporting that view too:
>>
>> https://tools.ietf.org/html/rfc7454which by the way also mentions the
>> ttl security feature mentioned (of course the
>>
>> approach is applicable for the igp too but this is another discussion.)
>>
>>
and then goes to say "These values may change in the future" as they
probably will, since our needs seem to change ever so often. BCPs have
always been driven by operators and operational experience. The whole
argument here is two-fold:
* until the IPv4 extinction and while IPv4 is a scarce resource,
people may need to announce larger prefixes simply because they
cannot be assigned shorter ones
* for IPv6, the /48 boundary is a bit arbitrary and once we gain
adequate operational experience, we might end up replacing it with a
longer one, simply because its wasteful (see also /127 for p2p links
instead of /64, /62 for residential customers instead of /56 etc.).
Our experience as an operator/ISP, shows just that and it seems that
other operators share the same experience
>> Further to that, it would be interesting to explore the opposite
>> viewi.e why someone would be willing to start propagating
>>
>> /25s and /26s? I don’t see a reason but there might be merits to that
>> view.
>>
>> 2. Bogon Ass should be filtered too:
>>
>> 0
>>
>> 23456
>>
>> 64496 – 131071
>>
>> 4200000000 – 4294967295
>>
>> RFC5398, RFC6996, RFC7300
>>
>> 3. We don’t do full automation and we will never do simply because
>> automation is not compatible with flexibility. The network is
>> more complex than an application.
>>
It's not really a matter of complexity (or it shouldn't be).
Automation+decision_making is not so futuristic anymore ;) . Machines
apparently do learn...
>> 3.
>> 4. The idea to write 250K lines of a prefix-listis not rational.
>> Simply doesn’t scale.
>> 5. There are no customer obligations there are obligations of any
>> internet citizen as stipulated by RIPE.
>> 6. The idea to outsourcefilteringto the provider is a pragmatic
>> oneandcan be part of the managed services portfoliooffered for
>> many years. The brave new world promises to lower
>>
>> barriers to market entry,empowering the provider withall these tasks.
>>
>> 7. How many of you have supported/adopted rfc 7999 wouldn’t that
>> make internet a better place?
>> 8. Also another aspect not mentioned but important is to encourage
>> the use of public but non publicly routable address space in the
>> interconnections.
>>
>> Regards,
>>
>>
>> /nikos
>>
>>
>>
>>
>>
>>
>> 2018-07-11 0:37 GMT+01:00 Andreas Polyrakis <apolyr at noc.grnet.gr
>> <mailto:apolyr at noc.grnet.gr>>:
>>
>> Καλησπέρα,
>>
>> Στον απόηχο ενός πολύ πετυχημένου GRNOG7*, θα θέλαμε να σας
>> ενημερώσουμε πως στη σελίδα της διοργάνωσης
>> <https://www.grnog.gr/7th-meeting/> έχουν αναρτηθεί οι
>> παρουσιάσεις, το βίντεο, φωτογραφίες και γενικότερα το υλικό της
>> συνάντησης.
>>
>> Θυμίζουμε πως η αξιολόγησή
>> <https://goo.gl/forms/0Q9Xcgnk060EG8Lz2> σας είναι σημαντική για
>> την διατήρηση του υψηλού επιπέδου της διοργάνωσης. Το link θα
>> παραμείνει ενεργό για λίγες ημέρες ακόμα.
>>
>> Και πάλι σας ευχαριστούμε θερμά για την ενεργή συμμετοχή σας!
>>
>> Η επιτροπή του GRNOG,
>> Κώστας Ζορμπαδέλος
>> Μιχάλης Μπερσίμης
>> Μιχάλης Οικονομάκος
>> Ανδρέας Πολυράκης
>>
>> * 111 εγγραφές, 11+2 παρουσιάσεις, ένα panel, με 3 ομιλητές να
>> ταξιδεύουν επί τούτου από το εξωτερικό και ένας από άλλη πόλη της
>> Ελλάδας, live streaming & recording -- και όλα αυτά σε ένα υπέρχο
>> χώρο!
>>
>>
>> --
>> -----------------------------------------------------------------------
>> Andreas Polyrakis -apolyr at noc.grnet.gr <mailto:apolyr at noc.grnet.gr>
>> GRNET NOC Technical Manager
>> Greek Research & Technology Network -http://www.grnet.gr
>> 7, Kifisias Av., Ampelokipi, 11523 Athens, Greece
>> <https://maps.google.com/?q=7,+Kifisias+Av.,+Ampelokipi,+11523+Athens,+Greece&entry=gmail&source=g>
>> Mobile: +30 6972832445 Office: +30 2107474249 Fax: +30 2107474490
>> -----------------------------------------------------------------------
>>
>>
>
> --
> ---------------------------------------------------------------
> Tasos Karaliotas -karaliot at noc.grnet.gr
> Greek Research& Technology Network -http://www.grnet.gr,
> 7, Kifisias Av., Ampelokipi, 11523 Athens, Greece
> Office: +302107471097 Fax: +302107474490
> ---------------------------------------------------------------
--
Yannis Nikolopoulos OTE S.A
e-mail: yanodd at otenet.gr IP Network Planning & Engineering
tel: +302106116293
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nogalliance.org/pipermail/grnog-members/attachments/20180713/0140ffbb/attachment.html>
More information about the grnog-members
mailing list