Re: sr - spring - what's the deal with 2 names

[Radu-Adrian Feurdean via NANOG]

On Sun, Sep 6, 2020, at 10:14, Jeff Tantsura via NANOG wrote:

> Out of curiosity - if you are interested in SR, where are you getting 
> your information from if not IETF (SPRING)?

Much beloved vendor claims support for "SPRINGv4" feature for a certain family 
of products (I personally expect something like SR, SR-MPLS or SRv6, definitely 
not SPRING).
Very big WTF, especially that that term is only found on 2 public pages : 
product family datasheet (PDF and HTML versions).

AT TV ISP Support

[Brian Pierce via NANOG]

Hello All,

Does anyone have reliable contact info for AT TV's ISP support? We are an ISP 
experiencing issues providing internet connectivity to AT TV boxes and we 
aren't having any luck reaching the correct support for this issue within AT 
TV's support structure. Has anyone worked with AT TV's support at the carrier 
level? Standard residential tech support has no idea how to assist us and is 
getting the run-around when they try to escalate the issue. We have tried 
reaching out to n...@att.net but they will not respond to 
our requests.

Thanks in advance,

Brian Pierce
Network Technician
bpie...@consolidated.coop

Consolidated Cooperative
consolidated.coop

Electric | Fiber | Gas
A Touchstone Energy* Cooperative
Light up your life.

Re: antispamcloud.com (SpamExperts) forensics reports format

[John Levine via NANOG]

In article <120a24d4e0da4f2392a25a8140be2...@ex1.obs.local> you write:
>We are parsing dmarc reports using parsedmarc and the forensics reports coming 
>from antispamcloud.com seems not to
>follow the recommended reporting format (AFRF) and therefore are considered 
>invalid.

You're right, they're not following the DMARC spec that says the reports
are sent in multipart/report ARF format.

Followups to the mailop list, where people who know about this stuff
are likely to read them.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Jeff Tantsura via NANOG]

BCP38 is an RFC, 2827.
It is a grand advise if you can:
-find someone who is actually well versed
-afford that someone.

Personally - when in early 2000s I had to write complete community tagging 
design for a multi country network, I wish I had  a “how to” 

Regards,
Jeff

> On Sep 9, 2020, at 15:35, adamv0...@netconsultings.com wrote:
> 
> 
> My advice to “someone who is setting up a new ISP and has a very little clue 
> as where to start” would be just don’t and instead hire someone who’s well 
> versed in this topic.
> But I see what you mean, RFC7938 was a good food for thought. But at the same 
> time I’m sceptical, for instance would it help if BCP38 was an RFC?
> Would be nice for instance if the community could put together a checklist of 
> things to consider for ISPs (could be in no particular order) (and actually 
> there are such lists albeit concentrated around security)   
>  
> adam
>  
> From: Jeff Tantsura  
> Sent: Wednesday, September 9, 2020 9:52 AM
> To: adamv0...@netconsultings.com
> Cc: nanog@nanog.org
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
>  
> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example 
> of “ab”use of ASN0 is a de-facto artifact (unfortunate one).
> My goal would be to provide a viable source of information to someone who is 
> setting up a new ISP and has a very little clue as where to start. Do’s and 
> don’t’s wrt inter-domain communities use. 
>  
> I really enjoyed the difference RFC7938 (Use of BGP for Routing in 
> Large-Scale Data Centers) made, literally 100s of companies have used it to 
> educate themselves/ implemented their DC networking.
>  
> Cheers,
> Jeff
> 
> 
> On Sep 9, 2020, at 10:04, adam via NANOG  wrote:
> 
> 
> I don’t agree with the use of reserved ASNs, let alone making it BCP, cause 
> it defeats the whole purpose of the community structure.
> Community is basically sending a message to an AS. If I want your specific AS 
> to interpret the message I set it in format YOUR_ASN:, your 
> AS in the first part of the community means that your rules of how to 
> interpret the community value apply.
> Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of 
> communities (or any other attribute for that matter) just doesn’t sit right 
> with me (what’s next? multicast-ASNs that we can subscribe to?).
> All the examples in Robert’s draft or wide community RFC, all of them use an 
> example AS# the community is addressed to (not some special reserved AS#).
>  
> Also should something like this become standard it needs to be properly 
> standardized and implemented as a well-known community by most vendors (like 
> RFCs defining the wide communities or addition to standard communities like 
> no_export/no_advertise/…). This would also eliminate the adoption friction 
> from operators rightly claiming “my AS my rules”.   
>  
> adam
>  
>  
> From: NANOG  On Behalf 
> Of Douglas Fischer via NANOG
> Sent: Tuesday, September 8, 2020 4:56 PM
> To: NANOG 
> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
>  
> Most of us have already used some BGP community policy to no-export some 
> routes to some where.
> 
> On the majority of IXPs, and most of the Transit Providers, the very common 
> community tell to route-servers and routers "Please do no-export these routes 
> to that ASN" is:
> 
>  -> 0:
>  
> So we could say that this is a de-facto standard.
>  
>  
> But the Policy equivalent to "Please, export these routes only to that ASN" 
> is very varied on all the IXPs or Transit Providers.
>  
>  
> With that said, now comes some questions:
> 
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
> something like that, that would define 0: as "no-export-to" 
> standard?
>  
> 2 - What about reserving some 16-bits ASN to use : as 
> "export-only-to" standard?
> 2.1 - Is important to be 16 bits, because with (RT) extended communities, any 
> ASN on the planet could be the target of that policy.
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
>  
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Jeff Tantsura via NANOG]

Great excuse ;-)

Regards,
Jeff

> On Sep 9, 2020, at 15:16, Mike Hammett via NANOG  wrote:
> 
> 
> If history has taught us anything, everything we do will be ignored by those 
> that most need it.  :-)
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Mark Tinka" 
> To: "Mike Hammett" 
> Cc: nanog@nanog.org
> Sent: Wednesday, September 9, 2020 7:59:55 AM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> Well, the proposed de facto standard is only useful for what we need to 
> signal outside of the AS.
> 
> Since an operator will still need to design for communities used internal to 
> the AS (which will have nothing to do with the outside world, and be of a 
> higher number), they can accomplish both tasks in one sitting; in lieu of 
> first designing for internal use, and then trying to design again for the 
> external standard.
> 
> At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
> on the well-known communities we have today, perhaps the industry should go 
> ahead and standardize this proposal anyway, and then see what happens. If 
> history has taught us anything, folk will do what they want for 23 or so 
> years, and even then, it might not turn out the way we hoped.
> 
> If it were me, I'd spend my time on other things. I can design internal 
> operator-specific communities that also do the right thing externally, if 
> needed. Heck, it's what I've done already. My customers are happy and I have 
> little incentive to fix that. 
> 
> But that's just me :-).
> 
> Mark.
> 
> On 9/Sep/20 14:47, Mike Hammett wrote:
> Exactly. There are far more pressing things when launching a new network than 
> coming up with a BGP community scheme from scratch, learning everyone else's 
> BGP community scheme, etc. If networks used a standard, then there is a very 
> minimal ramp-up.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Mark Tinka" 
> To: "Mike Hammett" 
> Cc: nanog@nanog.org
> Sent: Wednesday, September 9, 2020 6:47:13 AM
> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
> 
> 
> 
> On 9/Sep/20 13:41, Mike Hammett wrote:
> How is that any different than any other network with minimal connectivity 
> (say a non-ISP such as a school, medium business, local government, etc.)?
> 
> Because the existing flexibility of dis-aggregated BGP community design can 
> be done without any need to be in concert with the rest of the world, and 
> your network won't blow up. There are far more pressing things to consider 
> when launching a new network.
> 
> 
> 
> Also, it would likely help that new ISP in Myanmar learn their limited 
> upstream's communities if there were a standard.
> 
> There used to be a very large global transit network that did not support BGP 
> communities for their customers or peers. I'm not sure if that is still their 
> position in 2020, but back then, it did not stop them from growing quite well.
> 
> Mark.
> 
> 
> 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 17:42, Robert Raszuk wrote:
>
> It's not about numbers ... it's about ability to uniformly express
> policy with chain of arguments. 
>
> See even with large communities you can define a policy with an
> unstructured parameter and single action then you need to put it on
> all of your boxes to act upon. 
>
> Is it possible to perhaps express it there to do what you need today
> or what you think is possible today. 
>
> Imagine if you would be sending BGP updates between your internal
> peers and tell each peer how to read the encoding ... Doable - sure.
> Good idea - not quite.

I see your logic.

I'm not sure I want to put that much faith in vendors, to be honest.
Just look at how the RPKI communities were cocked up in not-so-recent
releases of Junos.

Would vendor code shipping with pre-defined, more well-known communities
make life easier? Sure, in theory.

Do I want that and still seek a 3AM snooze when the team decide to run a
revision update? Based on my experience, probably not.

But, if vendors (and enough operators) are horny for this kind of thing,
best thing to do would be to build it and see how it actually fares in
the field.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 17:52, Mike Hammett wrote:

> No, but most network operators also aren't NANOG members, attend NANOG
> shows, subscribe to NANOG lists.
>
> They're small outfits where there's between 1 - 5 total networking people.

Yeah, I'll steer clear of that one :-)...


>
> Circling back to earlier where I said there are almost 70k ASNs in use
> on the public Internet. Most of those operators don't have complex
> configurations. I'd be surprised if less than half of them had
> anything more than the most minimal default route configuration.

I don't know. If they are here, they can chime in.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

No, but most network operators also aren't NANOG members, attend NANOG shows, 
subscribe to NANOG lists. 


They're small outfits where there's between 1 - 5 total networking people. 


Circling back to earlier where I said there are almost 70k ASNs in use on the 
public Internet. Most of those operators don't have complex configurations. I'd 
be surprised if less than half of them had anything more than the most minimal 
default route configuration. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 8:13:32 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 15:06, Mike Hammett wrote: 




More operators don't use communities internally than the number of operators 
that do. 



Do you have some empirical data on that? 

I don't know if it's more, or less. But as Charlton Heston said in "True Lies": 

 
"So far this is not blowing my skirt up, gentlemen. Don't you have anything 
remotely substantial, Harry? Do you have any HARD DATA?" 
 

https://youtu.be/-KHkltl22V4?t=73 

:-)... 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Robert Raszuk via NANOG]

It's not about numbers ... it's about ability to uniformly express policy
with chain of arguments.

See even with large communities you can define a policy with an
unstructured parameter and single action then you need to put it on all of
your boxes to act upon.

Is it possible to perhaps express it there to do what you need today or
what you think is possible today.

Imagine if you would be sending BGP updates between your internal peers and
tell each peer how to read the encoding ... Doable - sure. Good idea - not
quite.

R.






On Wed, Sep 9, 2020 at 5:19 PM Mark Tinka  wrote:

>
>
> On 9/Sep/20 15:25, Robert Raszuk wrote:
>
> That's not quite true.
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and inter-domain use
> is to help you to use the same encoding acros policy engines of many
> vendors.
>
> I would actually risk to say that it could be even more applicable
> intra-domain then inter-domain.
>
> See the crux of the thing is that this is not just about putting bunch of
> type-codes into IANA reg. It is much more about uniform encoding for your
> actions with optional parameters across vendors.
>
> In fact the uphill on the implementation side is not because signalling
> new value in BGP is difficult to encode ... it is much more about taking
> those values and translating those to the run time policies in a
> flexible way.
>
>
> But how does that scale for vendors? Let me speak up for them on this one
> :-).
>
> We are now giving them extra work to write code to standardize communities
> for internal purposes. What extra benefit does that provide in lieu of the
> current method where Juniper send 1234:9876 to Cisco, and Cisco sees
> 1234:9876?
>
> Should a vendor be concerned about what purpose an internal community
> serves, as long as it does what the Autonomous System wants it to do?
>
> Unless I am totally misunderstanding your goal.
>
> Mark.
>

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 15:25, Robert Raszuk wrote:

> That's not quite true. 
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and
> inter-domain use is to help you to use the same encoding acros policy
> engines of many vendors. 
>
> I would actually risk to say that it could be even more applicable
> intra-domain then inter-domain. 
>
> See the crux of the thing is that this is not just about putting bunch
> of type-codes into IANA reg. It is much more about uniform encoding
> for your actions with optional parameters across vendors. 
>
> In fact the uphill on the implementation side is not
> because signalling new value in BGP is difficult to encode ... it is
> much more about taking those values and translating those to the run
> time policies in a flexible way. 

But how does that scale for vendors? Let me speak up for them on this
one :-).

We are now giving them extra work to write code to standardize
communities for internal purposes. What extra benefit does that provide
in lieu of the current method where Juniper send 1234:9876 to Cisco, and
Cisco sees 1234:9876?

Should a vendor be concerned about what purpose an internal community
serves, as long as it does what the Autonomous System wants it to do?

Unless I am totally misunderstanding your goal.

Mark.

Re: PTP/Syncronized Ethernet maturity

[m.Taichi via NANOG]

Hi Geir,

Gratefully thanks for your detailed sharing. Very informative and helpful
to our network's synchronization planning and operation.

We'll take your experiences into discussion and consideration. Get back to
share our experiences with you soon.

Thanks and best regards,
Taichi


On Wed, Sep 9, 2020 at 4:50 PM geir egeland 
wrote:

> Hi Taichi,
> It depends. GNSS at the cell site has its own operational challenges, for
> example making sure that the antenna has a clear enough view of the sky. A
> challenge in Asia is that very little of the fiber is in the ground, hence
> multiple fiber cuts happen on a daily basis which changes the path length
> when restoration mechanisms kicks in. A change in the path length is not a
> problem for PTP, but it require that we know the path asymmetry on all
> possible fiber paths between the master and the slave (we need to use
> protection on layer 1 in Asia due to the frequent fiber cuts).
> Another challenge with GNSS is that we experience that the GNSS is either
> jammed or even worse, that the GNSS is spoofed.
>
> When we did the PTP design, we also believed that the length of the fiber
> path length would be equal in both direction. However, in some of our old
> Metro networks, the line amplifier have embedded Dispersion
> Compensating Fiber (DCF) to compensate for the chromatic dispersion of
> different wavelengths. The length of fiber within DCF modules to compensate
> for the same length of fiber may vary significantly. Other parts in the
> optical domain can also cause asymmetry, e.g.transponders, software FEC, or
> FEC in general, and  digital signal processors in coherent optical systems.
> Asymmetry increases with link speed, so we could consider running PTP over
> 1GE interfaces, but this is a challenge in our Core networks.
>
> We can overcome the DCF (DCF is cheap) issue by either measure the
> asymmetry of every fiber hop (not practical possible),  change the DCP
> modules to Bragg filters (expensive), or deploy grand masters in the
> access/aggregation network in order to have less asymmetry impact from the
> fiber network.
>
> When it comes to the instabilities with PTP implementation, we try to work
> with the vendors so that they fix failing line cards, port flapping etc.
> However, its not always easy to get the vendor’s attention on PTP issues.
>
> OAM for PTP is another challenge, i.e. how can we make sure that the clock
> is healthy? We plan to solve this by deploying GNSS at certain locations in
> the network and use equipment that can compare the difference between
> GNSS-input and the received PTP clock.
>
> So key message is that PTP does not work out of the box, it requires
> significant engineering effort. GNSS has many issues as well, and in
> certain parts of Europe we cannot rely on GNSS only. So it is not an
> either-or, -  we need both.
>
> best regards,
> Geir
>
> On 8 Sep 2020, at 18:11, m.Taichi  wrote:
>
>
> Hi Geir,
>
> Can we say, from your production network experiences across Asia and
> Europe, that getting synchronization clock signal via GNSS receiver
> directly on each cell site is a much more reliable, stable, and simpler way
> than getting it by network-based PTP? Especially when there is WDM link
> used in between the BC and Slave Clock?
>
> Why does WDM link cause path asymmetry? I thought the optical fibers carry
> forward link and reverse link are almost equal in length (distance). Aren't
> they?
>
> What are your solutions to overcome the PTP synchronization instability
> problems in your TDD 4G/5G networks?
>
> Thanks and best regards,
> Taichi
>
>
> On Tue, Sep 8, 2020 at 11:09 PM geir egeland via NANOG 
> wrote:
>
>> We have mobile NWs in both Asia and Europe and also experience a lot of
>> issues with PTP, - almost with every vendor.
>> The instabilities, SW-bugs etc. related to PTP seems to indicate that
>> very little testing of this code has been done in production networks. In
>> some deployments we have been able to produce a clock service by installing
>> GNSS on the cell-site. However, in other countries there are regulatory
>> directives that the phase sync must be PTP/Network based.
>>
>> Currently, the optical domain is causing us huge problems when we try to
>> engineer a T-BC/PTP solution. This is due to the path asymmetry that exist
>> in the WDM/fiber domain. In some networks we have a lot of DCF in the fiber
>> path and the only way we can get visibility in the asymmetry on these fiber
>> hops is to measure in both direction:(
>> Also, running T-BC over WDM/OTN will simply not work as the phase error
>> introduced more or less eats up the phase error budget for 4G/5G
>> TDD-service.
>>
>> best regards,
>> Geir
>>
>> On 5 Sep 2020, at 00:17, Macho Pellegrini via NANOG 
>> wrote:
>>
>> Hello everybody,
>>
>> We have deployed PTP in our mobile NW since late 2019 as a part of the
>> 4G/5G, however we are seeing a lots of instabilities and interop issues, a
>> lot of the issues have ended up with 

antispamcloud.com (SpamExperts) forensics reports format

[Sébastien Riccio via NANOG]

Hello,

We are parsing dmarc reports using parsedmarc and the forensics reports coming 
from antispamcloud.com seems not to follow the recommended reporting format 
(AFRF) and therefore are considered invalid.

Maybe is there anyone from SpamExperts in this list that could enlighten me 
about how we could request to receive the reports in a common format?

If I understand correctly that should be the case by default:

https://tools.ietf.org/html/rfc7489#section-7.3
When a Domain Owner requests failure reports for the purpose of
forensic analysis, and the Mail Receiver is willing to provide such
reports, the Mail Receiver generates and sends a message using the
format described in [AFRF]; this document updates that reporting
format, as described in Section 7.3.1.

https://tools.ietf.org/html/rfc7489#section-6.3
rf:  Format to be used for message-specific failure reports (colon-
  separated plain-text list of values; OPTIONAL; default is "afrf").
  The value of this tag is a list of one or more report formats as
  requested by the Domain Owner to be used when a message fails both
  [SPF] and [DKIM] tests to report details of the individual
  failure.  The values MUST be present in the registry of reporting
  formats defined in Section 11; a Mail Receiver observing a
  different value SHOULD ignore it or MAY ignore the entire DMARC
  record.  For this version, only "afrf" (the auth-failure report
  type defined in [AFRF]) is presently supported.  See Section 7.3
  for details.  For interoperability, the Authentication Failure
  Reporting Format (AFRF) MUST be supported.


Instead we receive it with this format:

A message claiming to be from you has failed the published DMARC
policy for your domain.

  Sender Domain: xyz.ch
  Sender IP Address: x.x.x.x
  Received Date: Fri, 04 Sep 2020 16:37:40 +0200
  SPF Alignment: no
  DKIM Alignment: no
  DMARC Results: None, Accept

-- This is a copy of the headers that were received before the error
   was detected.


[then all headers of the offending message here that I removed for this post]


Thanks a lot for your infos and help.

Kind regards,

Sébastien RICCIO
SYSTEM ADMINISTRATOR
P  +41 840 888 888
F  +41 840 888 000
M sric...@swisscenter.com

RE: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[adam via NANOG]

> Chriztoffer Hansen via NANOG
> Sent: Wednesday, September 9, 2020 1:29 PM
> 
> On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG 
> wrote:
> > It's not unlike trusting your customers to send you FlowSpec 
> > instructions. No issues technically, but do you want to do it?
> 
> Why not? As a service offering, it makes total sense.
> 
> Thou, generally I agree with you. Trust, but verify any received 
> announcement conforms to a base-set of expectations. Discard non- 
> conforming.
> 
Yeah right, like you all are limiting max length of as_path, dropping boggon 
ASNs, or limiting max number of communities or striping unused/unsupported 
attributes on ingress to your AS...
Or otherwise test what happens to your border edge (or internet-plane 
route-reflectors/ iBGP infrastructure for that matter) if exposed to these.

adam

RE: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[adam via NANOG]

My advice to “someone who is setting up a new ISP and has a very little clue as 
where to start” would be just don’t and instead hire someone who’s well versed 
in this topic.

But I see what you mean, RFC7938 was a good food for thought. But at the same 
time I’m sceptical, for instance would it help if BCP38 was an RFC? 

Would be nice for instance if the community could put together a checklist of 
things to consider for ISPs (could be in no particular order) (and actually 
there are such lists albeit concentrated around security)   

 

adam

 

From: Jeff Tantsura  
Sent: Wednesday, September 9, 2020 9:52 AM
To: adamv0...@netconsultings.com
Cc: nanog@nanog.org
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of 
“ab”use of ASN0 is a de-facto artifact (unfortunate one).

My goal would be to provide a viable source of information to someone who is 
setting up a new ISP and has a very little clue as where to start. Do’s and 
don’t’s wrt inter-domain communities use. 

 

I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale 
Data Centers) made, literally 100s of companies have used it to educate 
themselves/ implemented their DC networking.

 

Cheers,

Jeff





On Sep 9, 2020, at 10:04, adam via NANOG mailto:nanog@nanog.org> > wrote:



I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it 
defeats the whole purpose of the community structure.

Community is basically sending a message to an AS. If I want your specific AS 
to interpret the message I set it in format YOUR_ASN:, your AS 
in the first part of the community means that your rules of how to interpret 
the community value apply.

Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of 
communities (or any other attribute for that matter) just doesn’t sit right 
with me (what’s next? multicast-ASNs that we can subscribe to?).

All the examples in Robert’s draft or wide community RFC, all of them use an 
example AS# the community is addressed to (not some special reserved AS#).

 

Also should something like this become standard it needs to be properly 
standardized and implemented as a well-known community by most vendors (like 
RFCs defining the wide communities or addition to standard communities like 
no_export/no_advertise/…). This would also eliminate the adoption friction from 
operators rightly claiming “my AS my rules”.   

 

adam

 

 

From: NANOG mailto:nanog-bounces+adamv0025=netconsultings@nanog.org> > On Behalf Of 
Douglas Fischer via NANOG
Sent: Tuesday, September 8, 2020 4:56 PM
To: NANOG mailto:nanog@nanog.org> >
Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

Most of us have already used some BGP community policy to no-export some routes 
to some where.

On the majority of IXPs, and most of the Transit Providers, the very common 
community tell to route-servers and routers "Please do no-export these routes 
to that ASN" is:

 -> 0:

 

So we could say that this is a de-facto standard.

 

 

But the Policy equivalent to "Please, export these routes only to that ASN" is 
very varied on all the IXPs or Transit Providers.

 

 

With that said, now comes some questions:

1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
something like that, that would define 0: as "no-export-to" standard?

 

2 - What about reserving some 16-bits ASN to use : as 
"export-only-to" standard?

2.1 - Is important to be 16 bits, because with (RT) extended communities, any 
ASN on the planet could be the target of that policy.

2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Robert Raszuk via NANOG]

>
> Well, the proposed de facto standard is only useful for what we need to
> signal outside of the AS.


That's not quite true.

See the entire idea behind defining a common mechanism for signalling
policy in communities in a flexible way for both intra and inter-domain use
is to help you to use the same encoding acros policy engines of many
vendors.

I would actually risk to say that it could be even more applicable
intra-domain then inter-domain.

See the crux of the thing is that this is not just about putting bunch of
type-codes into IANA reg. It is much more about uniform encoding for your
actions with optional parameters across vendors.

In fact the uphill on the implementation side is not because signalling new
value in BGP is difficult to encode ... it is much more about taking those
values and translating those to the run time policies in a flexible way.

Thx,
R.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 15:09, Mike Hammett wrote:

> If history has taught us anything, everything we do will be ignored by
> those that most need it.  :-)

Touche :-)...

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 15:06, Mike Hammett wrote:

> More operators don't use communities internally than the number of
> operators that do.

Do you have some empirical data on that?

I don't know if it's more, or less. But as Charlton Heston said in "True
Lies":


"So far this is not blowing my skirt up, gentlemen. Don't you have
anything remotely substantial, Harry? Do you have any HARD DATA?"


    https://youtu.be/-KHkltl22V4?t=73

:-)...

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

If history has taught us anything, everything we do will be ignored by those 
that most need it. :-) 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 7:59:55 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 

Well, the proposed de facto standard is only useful for what we need to signal 
outside of the AS. 

Since an operator will still need to design for communities used internal to 
the AS (which will have nothing to do with the outside world, and be of a 
higher number), they can accomplish both tasks in one sitting; in lieu of first 
designing for internal use, and then trying to design again for the external 
standard. 

At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
on the well-known communities we have today, perhaps the industry should go 
ahead and standardize this proposal anyway, and then see what happens. If 
history has taught us anything, folk will do what they want for 23 or so years, 
and even then, it might not turn out the way we hoped. 

If it were me, I'd spend my time on other things. I can design internal 
operator-specific communities that also do the right thing externally, if 
needed. Heck, it's what I've done already. My customers are happy and I have 
little incentive to fix that. 

But that's just me :-). 

Mark. 


On 9/Sep/20 14:47, Mike Hammett wrote: 



Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 14:29, Chriztoffer Hansen wrote:

> Why not? As a service offering, it makes total sense.

Yes, makes total sense.

So why aren't jumping all over it?


>
> Thou, generally I agree with you. Trust, but verify any received
> announcement conforms to a base-set of expectations. Discard
> non-conforming.

This. But as always, the plan is what happens.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

More operators don't use communities internally than the number of operators 
that do. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 7:59:55 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 

Well, the proposed de facto standard is only useful for what we need to signal 
outside of the AS. 

Since an operator will still need to design for communities used internal to 
the AS (which will have nothing to do with the outside world, and be of a 
higher number), they can accomplish both tasks in one sitting; in lieu of first 
designing for internal use, and then trying to design again for the external 
standard. 

At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree 
on the well-known communities we have today, perhaps the industry should go 
ahead and standardize this proposal anyway, and then see what happens. If 
history has taught us anything, folk will do what they want for 23 or so years, 
and even then, it might not turn out the way we hoped. 

If it were me, I'd spend my time on other things. I can design internal 
operator-specific communities that also do the right thing externally, if 
needed. Heck, it's what I've done already. My customers are happy and I have 
little incentive to fix that. 

But that's just me :-). 

Mark. 


On 9/Sep/20 14:47, Mike Hammett wrote: 



Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

Well, the proposed de facto standard is only useful for what we need to
signal outside of the AS.

Since an operator will still need to design for communities used
internal to the AS (which will have nothing to do with the outside
world, and be of a higher number), they can accomplish both tasks in one
sitting; in lieu of first designing for internal use, and then trying to
design again for the external standard.

At any rate, as Nick said yesterday, if it's taken us over 2 decades to
agree on the well-known communities we have today, perhaps the industry
should go ahead and standardize this proposal anyway, and then see what
happens. If history has taught us anything, folk will do what they want
for 23 or so years, and even then, it might not turn out the way we hoped.

If it were me, I'd spend my time on other things. I can design internal
operator-specific communities that also do the right thing externally,
if needed. Heck, it's what I've done already. My customers are happy and
I have little incentive to fix that.

But that's just me :-).

Mark.

On 9/Sep/20 14:47, Mike Hammett wrote:
> Exactly. There are far more pressing things when launching a new
> network than coming up with a BGP community scheme from scratch,
> learning everyone else's BGP community scheme, etc. If networks used a
> standard, then there is a very minimal ramp-up.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> *From: *"Mark Tinka" 
> *To: *"Mike Hammett" 
> *Cc: *nanog@nanog.org
> *Sent: *Wednesday, September 9, 2020 6:47:13 AM
> *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker -
> Any ASN reserved to "export-only-to"?'
>
>
>
> On 9/Sep/20 13:41, Mike Hammett wrote:
>
> How is that any different than any other network with minimal
> connectivity (say a non-ISP such as a school, medium business,
> local government, etc.)?
>
>
> Because the existing flexibility of dis-aggregated BGP community
> design can be done without any need to be in concert with the rest of
> the world, and your network won't blow up. There are far more pressing
> things to consider when launching a new network.
>
>
>
> Also, it would likely help that new ISP in Myanmar learn their
> limited upstream's communities if there were a standard.
>
>
> There used to be a very large global transit network that did not
> support BGP communities for their customers or peers. I'm not sure if
> that is still their position in 2020, but back then, it did not stop
> them from growing quite well.
>
> Mark.
>

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

Exactly. There are far more pressing things when launching a new network than 
coming up with a BGP community scheme from scratch, learning everyone else's 
BGP community scheme, etc. If networks used a standard, then there is a very 
minimal ramp-up. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, September 9, 2020 6:47:13 AM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 9/Sep/20 13:41, Mike Hammett wrote: 



How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Because the existing flexibility of dis-aggregated BGP community design can be 
done without any need to be in concert with the rest of the world, and your 
network won't blow up. There are far more pressing things to consider when 
launching a new network. 








Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 



There used to be a very large global transit network that did not support BGP 
communities for their customers or peers. I'm not sure if that is still their 
position in 2020, but back then, it did not stop them from growing quite well. 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Chriztoffer Hansen via NANOG]

On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG  wrote:
> It's not unlike trusting your customers to send you FlowSpec
> instructions. No issues technically, but do you want to do it?

Why not? As a service offering, it makes total sense.

Thou, generally I agree with you. Trust, but verify any received
announcement conforms to a base-set of expectations. Discard
non-conforming.

-- 

Chriztoffer

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 13:41, Mike Hammett wrote:
> How is that any different than any other network with minimal
> connectivity (say a non-ISP such as a school, medium business, local
> government, etc.)?

Because the existing flexibility of dis-aggregated BGP community design
can be done without any need to be in concert with the rest of the
world, and your network won't blow up. There are far more pressing
things to consider when launching a new network.


>
> Also, it would likely help that new ISP in Myanmar learn their limited
> upstream's communities if there were a standard.

There used to be a very large global transit network that did not
support BGP communities for their customers or peers. I'm not sure if
that is still their position in 2020, but back then, it did not stop
them from growing quite well.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

How is that any different than any other network with minimal connectivity (say 
a non-ISP such as a school, medium business, local government, etc.)? 


Also, it would likely help that new ISP in Myanmar learn their limited 
upstream's communities if there were a standard. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka via NANOG"  
To: nanog@nanog.org 
Sent: Tuesday, September 8, 2020 11:28:48 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 



On 8/Sep/20 22:02, Tom Beecher via NANOG wrote: 

> I also get that intent from the OP. However I disagree that there 
> should be a 'de facto' standard created for such things. All flavors 
> of BGP community specifications are designed to be flexible so that 
> different networks can design a system that is tailored to their needs. 
> 
> Having 'de facto' standards does not simplify in my opinion. I 
> believe it just creates more work for operators trying to navigate 
> around different opinions of what 'de facto' means. 

Indeed. 

Consider a new ISP starting operations in Myanmar, with little or no 
global peering, having to wade through tons of information to design 
their BGP community structure based on a "de facto" standard defined by 
a group of ISP's half-way around the world. 

What's the real value? 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mike Hammett via NANOG]

I don't think the OP cares about what you do internally. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mark Tinka via NANOG"  
To: nanog@nanog.org 
Sent: Tuesday, September 8, 2020 11:26:43 PM 
Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?' 




On 8/Sep/20 20:35, Mike Hammett via NANOG wrote: 




How I see the OP's intent is to create a BCP of what defined communities have 
what effect instead of everyone just making up whatever they draw out of a hat, 
simplifying this process for everyone. 



Which only matters if you are extending a community outside of your own network 
to someone else's. 

If the communities are to be used internally, then it doesn't matter what 
definition an operator uses. 

Mark. 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Jeff Tantsura via NANOG]

Robert,

This is not whether you should do it, but, should you have decided to, how to 
do it in the best possible way, without making mistakes someone else has made 
and learnt from.

Regards,
Jeff

> On Sep 9, 2020, at 11:40, Robert Raszuk  wrote:
> 
> 
> And use of BGP without IGP left and right when even today bunch of DCs can do 
> just fine with current IGPs scaling wise is IMO not a good thing.
> 
> Thx
> R.
> 
>> On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG  wrote:
>> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example 
>> of “ab”use of ASN0 is a de-facto artifact (unfortunate one).
>> My goal would be to provide a viable source of information to someone who is 
>> setting up a new ISP and has a very little clue as where to start. Do’s and 
>> don’t’s wrt inter-domain communities use. 
>> 
>> I really enjoyed the difference RFC7938 (Use of BGP for Routing in 
>> Large-Scale Data Centers) made, literally 100s of companies have used it to 
>> educate themselves/ implemented their DC networking.
>> 
>> Cheers,
>> Jeff
>> 
 On Sep 9, 2020, at 10:04, adam via NANOG  wrote:
 
>>> 
>>> I don’t agree with the use of reserved ASNs, let alone making it BCP, cause 
>>> it defeats the whole purpose of the community structure.
>>> 
>>> Community is basically sending a message to an AS. If I want your specific 
>>> AS to interpret the message I set it in format YOUR_ASN:, 
>>> your AS in the first part of the community means that your rules of how to 
>>> interpret the community value apply.
>>> 
>>> Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of 
>>> communities (or any other attribute for that matter) just doesn’t sit right 
>>> with me (what’s next? multicast-ASNs that we can subscribe to?).
>>> 
>>> All the examples in Robert’s draft or wide community RFC, all of them use 
>>> an example AS# the community is addressed to (not some special reserved 
>>> AS#).
>>> 
>>>  
>>> 
>>> Also should something like this become standard it needs to be properly 
>>> standardized and implemented as a well-known community by most vendors 
>>> (like RFCs defining the wide communities or addition to standard 
>>> communities like no_export/no_advertise/…). This would also eliminate the 
>>> adoption friction from operators rightly claiming “my AS my rules”.   
>>> 
>>>  
>>> 
>>> adam
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: NANOG  On 
>>> Behalf Of Douglas Fischer via NANOG
>>> Sent: Tuesday, September 8, 2020 4:56 PM
>>> To: NANOG 
>>> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
>>> reserved to "export-only-to"?'
>>> 
>>>  
>>> 
>>> Most of us have already used some BGP community policy to no-export some 
>>> routes to some where.
>>> 
>>> On the majority of IXPs, and most of the Transit Providers, the very common 
>>> community tell to route-servers and routers "Please do no-export these 
>>> routes to that ASN" is:
>>> 
>>>  -> 0:
>>> 
>>>  
>>> 
>>> So we could say that this is a de-facto standard.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> But the Policy equivalent to "Please, export these routes only to that ASN" 
>>> is very varied on all the IXPs or Transit Providers.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> With that said, now comes some questions:
>>> 
>>> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
>>> something like that, that would define 0: as "no-export-to" 
>>> standard?
>>> 
>>>  
>>> 
>>> 2 - What about reserving some 16-bits ASN to use : as 
>>> "export-only-to" standard?
>>> 
>>> 2.1 - Is important to be 16 bits, because with (RT) extended communities, 
>>> any ASN on the planet could be the target of that policy.
>>> 
>>> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
>>> 
>>>  
>>> 
>>> --
>>> 
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Nick Hilliard via NANOG]

Jeff Tantsura via NANOG wrote on 09/09/2020 09:03:
De-facto standards are as good as people implementing them, however in 
order to enforce non ambiguous implementations, it has to be de-jure 
(e.g. a standard track RFC).

While I’m sympathetic to the idea, I’m quite skeptical about its viability.
A well written BCP would be much more valuable, and perhaps when we get 
to a critical mass, codification would be a natural process, rather than 
artificially enforcing people doing stuff they don’t see value (ROI) in, 
discussion here perfectly reflects the state of art.


Last year the IETF published RFC 8642, "Policy Behavior for Well-Known 
BGP Communities" which described how the three well-known communities 
defined in RFC1997 ought to be interpreted.  RFC1997 was published in 
1996, 23 years prior, and the definitions looked pretty simple and 
unambiguous.


Here's the opening paragraph:


   The BGP Communities attribute was specified in [RFC1997], which
   introduced the concept of well-known communities.  In hindsight,
   [RFC1997] did not prescribe as fully as it should have how well-known
   communities may be manipulated by policies applied by operators.
   Currently, implementations differ in this regard, and these
   differences can result in inconsistent behaviors that operators find
   difficult to identify and resolve.


I sympathise with the idea of standardised well-known communities, but 
if it takes us 23 years to tie down the semantics of three simple WKCs 
to the point that they behave consistently across vendors and operators, 
it's going to be a real struggle to define anything more complicated to 
the point that they end up doing what we want them to do, which is to 
say that they behave consistently across NOS implementations and 
different operator networks.


Even mixing 16-bit communities and 32-bit communities for stuff like ixp 
route server no-export causes interoperability problems.  Which gets 
evaluated first?  Why?  What happens if you get the order wrong? How can 
you integrate this into an existing routing policy configuration?


These things look a bit academic until something breaks, at which point 
it becomes clear that even simple-looking stuff can be complicated and 
messy when it goes wrong.


Nick

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Robert Raszuk via NANOG]

And use of BGP without IGP left and right when even today bunch of DCs can
do just fine with current IGPs scaling wise is IMO not a good thing.

Thx
R.

On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG  wrote:

> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP,
> example of “ab”use of ASN0 is a de-facto artifact (unfortunate one).
> My goal would be to provide a viable source of information to someone who
> is setting up a new ISP and has a very little clue as where to start. Do’s
> and don’t’s wrt inter-domain communities use.
>
> I really enjoyed the difference RFC7938 (Use of BGP for Routing in
> Large-Scale Data Centers) made, literally 100s of companies have used it
> to educate themselves/ implemented their DC networking.
>
> Cheers,
> Jeff
>
> On Sep 9, 2020, at 10:04, adam via NANOG  wrote:
>
> 
>
> I don’t agree with the use of reserved ASNs, let alone making it BCP,
> cause it defeats the whole purpose of the community structure.
>
> Community is basically sending a message to an AS. If I want your specific
> AS to interpret the message I set it in format YOUR_ASN:,
> your AS in the first part of the community means that your rules of how to
> interpret the community value apply.
>
> Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of
> communities (or any other attribute for that matter) just doesn’t sit right
> with me (what’s next? multicast-ASNs that we can subscribe to?).
>
> All the examples in Robert’s draft or wide community RFC, all of them use
> an example AS# the community is addressed to (not some special reserved
> AS#).
>
>
>
> Also should something like this become standard it needs to be properly
> standardized and implemented as a well-known community by most vendors
> (like RFCs defining the wide communities or addition to standard
> communities like no_export/no_advertise/…). This would also eliminate the
> adoption friction from operators rightly claiming “my AS my rules”.
>
>
>
> adam
>
>
>
>
>
> *From:* NANOG  *On
> Behalf Of *Douglas Fischer via NANOG
> *Sent:* Tuesday, September 8, 2020 4:56 PM
> *To:* NANOG 
> *Subject:* BGP Community - AS0 is de-facto "no-export-to" marker - Any
> ASN reserved to "export-only-to"?'
>
>
>
> Most of us have already used some BGP community policy to no-export some
> routes to some where.
>
> On the majority of IXPs, and most of the Transit Providers, the very
> common community tell to route-servers and routers "Please do no-export
> these routes to that ASN" is:
>
>  -> 0:
>
>
>
> So we could say that this is a de-facto standard.
>
>
>
>
>
> But the Policy equivalent to "Please, export these routes only to that
> ASN" is very varied on all the IXPs or Transit Providers.
>
>
>
>
>
> With that said, now comes some questions:
>
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or
> something like that, that would define 0: as "no-export-to"
> standard?
>
>
>
> 2 - What about reserving some 16-bits ASN to use :
> as "export-only-to" standard?
>
> 2.1 - Is important to be 16 bits, because with (RT) extended communities,
> any ASN on the planet could be the target of that policy.
>
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Jeff Tantsura via NANOG]

I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of 
“ab”use of ASN0 is a de-facto artifact (unfortunate one).
My goal would be to provide a viable source of information to someone who is 
setting up a new ISP and has a very little clue as where to start. Do’s and 
don’t’s wrt inter-domain communities use. 

I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale 
Data Centers) made, literally 100s of companies have used it to educate 
themselves/ implemented their DC networking.

Cheers,
Jeff

>> On Sep 9, 2020, at 10:04, adam via NANOG  wrote:
> 
> I don’t agree with the use of reserved ASNs, let alone making it BCP, cause 
> it defeats the whole purpose of the community structure.
> Community is basically sending a message to an AS. If I want your specific AS 
> to interpret the message I set it in format YOUR_ASN:, your 
> AS in the first part of the community means that your rules of how to 
> interpret the community value apply.
> Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of 
> communities (or any other attribute for that matter) just doesn’t sit right 
> with me (what’s next? multicast-ASNs that we can subscribe to?).
> All the examples in Robert’s draft or wide community RFC, all of them use an 
> example AS# the community is addressed to (not some special reserved AS#).
>  
> Also should something like this become standard it needs to be properly 
> standardized and implemented as a well-known community by most vendors (like 
> RFCs defining the wide communities or addition to standard communities like 
> no_export/no_advertise/…). This would also eliminate the adoption friction 
> from operators rightly claiming “my AS my rules”.   
>  
> adam
>  
>  
> From: NANOG  On Behalf 
> Of Douglas Fischer via NANOG
> Sent: Tuesday, September 8, 2020 4:56 PM
> To: NANOG 
> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
> reserved to "export-only-to"?'
>  
> Most of us have already used some BGP community policy to no-export some 
> routes to some where.
> 
> On the majority of IXPs, and most of the Transit Providers, the very common 
> community tell to route-servers and routers "Please do no-export these routes 
> to that ASN" is:
> 
>  -> 0:
>  
> So we could say that this is a de-facto standard.
>  
>  
> But the Policy equivalent to "Please, export these routes only to that ASN" 
> is very varied on all the IXPs or Transit Providers.
>  
>  
> With that said, now comes some questions:
> 
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
> something like that, that would define 0: as "no-export-to" 
> standard?
>  
> 2 - What about reserving some 16-bits ASN to use : as 
> "export-only-to" standard?
> 2.1 - Is important to be 16 bits, because with (RT) extended communities, any 
> ASN on the planet could be the target of that policy.
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
>  
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: PTP/Syncronized Ethernet maturity

[geir egeland via NANOG]

Hi Taichi,
It depends. GNSS at the cell site has its own operational challenges, for 
example making sure that the antenna has a clear enough view of the sky. A 
challenge in Asia is that very little of the fiber is in the ground, hence 
multiple fiber cuts happen on a daily basis which changes the path length when 
restoration mechanisms kicks in. A change in the path length is not a problem 
for PTP, but it require that we know the path asymmetry on all possible fiber 
paths between the master and the slave (we need to use protection on layer 1 in 
Asia due to the frequent fiber cuts).
Another challenge with GNSS is that we experience that the GNSS is either 
jammed or even worse, that the GNSS is spoofed.
 
When we did the PTP design, we also believed that the length of the fiber path 
length would be equal in both direction. However, in some of our old Metro 
networks, the line amplifier have embedded Dispersion Compensating Fiber (DCF) 
to compensate for the chromatic dispersion of different wavelengths. The length 
of fiber within DCF modules to compensate for the same length of fiber may vary 
significantly. Other parts in the optical domain can also cause asymmetry, 
e.g.transponders, software FEC, or FEC in general, and  digital signal 
processors in coherent optical systems. Asymmetry increases with link speed, so 
we could consider running PTP over 1GE interfaces, but this is a challenge in 
our Core networks.
 
We can overcome the DCF (DCF is cheap) issue by either measure the asymmetry of 
every fiber hop (not practical possible),  change the DCP modules to Bragg 
filters (expensive), or deploy grand masters in the access/aggregation network 
in order to have less asymmetry impact from the fiber network. 
 
When it comes to the instabilities with PTP implementation, we try to work with 
the vendors so that they fix failing line cards, port flapping etc. However, 
its not always easy to get the vendor’s attention on PTP issues.
 
OAM for PTP is another challenge, i.e. how can we make sure that the clock is 
healthy? We plan to solve this by deploying GNSS at certain locations in the 
network and use equipment that can compare the difference between GNSS-input 
and the received PTP clock.
 
So key message is that PTP does not work out of the box, it requires 
significant engineering effort. GNSS has many issues as well, and in certain 
parts of Europe we cannot rely on GNSS only. So it is not an either-or, -  we 
need both.

best regards,
Geir

> On 8 Sep 2020, at 18:11, m.Taichi  wrote:
> 
> 
> Hi Geir,
> 
> Can we say, from your production network experiences across Asia and Europe, 
> that getting synchronization clock signal via GNSS receiver directly on each 
> cell site is a much more reliable, stable, and simpler way than getting it by 
> network-based PTP? Especially when there is WDM link used in between the BC 
> and Slave Clock?
> 
> Why does WDM link cause path asymmetry? I thought the optical fibers carry 
> forward link and reverse link are almost equal in length (distance). Aren't 
> they?
> 
> What are your solutions to overcome the PTP synchronization instability 
> problems in your TDD 4G/5G networks?
> 
> Thanks and best regards,
> Taichi
> 
> 
> On Tue, Sep 8, 2020 at 11:09 PM geir egeland via NANOG  > wrote:
> We have mobile NWs in both Asia and Europe and also experience a lot of 
> issues with PTP, - almost with every vendor.
> The instabilities, SW-bugs etc. related to PTP seems to indicate that very 
> little testing of this code has been done in production networks. In some 
> deployments we have been able to produce a clock service by installing GNSS 
> on the cell-site. However, in other countries there are regulatory directives 
> that the phase sync must be PTP/Network based.
>  
> Currently, the optical domain is causing us huge problems when we try to 
> engineer a T-BC/PTP solution. This is due to the path asymmetry that exist in 
> the WDM/fiber domain. In some networks we have a lot of DCF in the fiber path 
> and the only way we can get visibility in the asymmetry on these fiber hops 
> is to measure in both direction:(
> Also, running T-BC over WDM/OTN will simply not work as the phase error 
> introduced more or less eats up the phase error budget for 4G/5G TDD-service. 
> 
> best regards,
> Geir
> 
>> On 5 Sep 2020, at 00:17, Macho Pellegrini via NANOG > > wrote:
>> 
>> Hello everybody,
>> 
>> We have deployed PTP in our mobile NW since late 2019 as a part of the 
>> 4G/5G, however we are seeing a lots of instabilities and interop issues, a 
>> lot of the issues have ended up with SW bugs in the OS, I have no specific 
>> question, however I got the impression that the technology/protocol is not 
>> yet mature, anybody here got his hands dirty with PTP?
>> 
>> Thanks,
>> MP
> 

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 10:03, Jeff Tantsura via NANOG wrote:

> De-facto standards are as good as people implementing them, however in
> order to enforce non ambiguous implementations, it has to be de-jure
> (e.g. a standard track RFC).
> While I’m sympathetic to the idea, I’m quite skeptical about its
> viability.
> A well written BCP would be much more valuable, and perhaps when we
> get to a critical mass, codification would be a natural process,
> rather than artificially enforcing people doing stuff they don’t see
> value (ROI) in, discussion here perfectly reflects the state of art.

This.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Jeff Tantsura via NANOG]

De-facto standards are as good as people implementing them, however in order to 
enforce non ambiguous implementations, it has to be de-jure (e.g. a standard 
track RFC).
While I’m sympathetic to the idea, I’m quite skeptical about its viability.
A well written BCP would be much more valuable, and perhaps when we get to a 
critical mass, codification would be a natural process, rather than 
artificially enforcing people doing stuff they don’t see value (ROI) in, 
discussion here perfectly reflects the state of art.

Cheers,
Jeff

> On Sep 8, 2020, at 17:57, Douglas Fischer via NANOG  wrote:
> 
> 
> Most of us have already used some BGP community policy to no-export some 
> routes to some where.
> 
> On the majority of IXPs, and most of the Transit Providers, the very common 
> community tell to route-servers and routers "Please do no-export these routes 
> to that ASN" is:
> 
>  -> 0:
> 
> So we could say that this is a de-facto standard.
> 
> 
> But the Policy equivalent to "Please, export these routes only to that ASN" 
> is very varied on all the IXPs or Transit Providers.
> 
> 
> With that said, now comes some questions:
> 
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
> something like that, that would define 0: as "no-export-to" 
> standard?
> 
> 2 - What about reserving some 16-bits ASN to use : as 
> "export-only-to" standard?
> 2.1 - Is important to be 16 bits, because with (RT) extended communities, any 
> ASN on the planet could be the target of that policy.
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

RE: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[adam via NANOG]

I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it 
defeats the whole purpose of the community structure.

Community is basically sending a message to an AS. If I want your specific AS 
to interpret the message I set it in format YOUR_ASN:, your AS 
in the first part of the community means that your rules of how to interpret 
the community value apply.

Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of 
communities (or any other attribute for that matter) just doesn’t sit right 
with me (what’s next? multicast-ASNs that we can subscribe to?).

All the examples in Robert’s draft or wide community RFC, all of them use an 
example AS# the community is addressed to (not some special reserved AS#).

 

Also should something like this become standard it needs to be properly 
standardized and implemented as a well-known community by most vendors (like 
RFCs defining the wide communities or addition to standard communities like 
no_export/no_advertise/…). This would also eliminate the adoption friction from 
operators rightly claiming “my AS my rules”.   

 

adam

 

 

From: NANOG  On Behalf Of 
Douglas Fischer via NANOG
Sent: Tuesday, September 8, 2020 4:56 PM
To: NANOG 
Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN 
reserved to "export-only-to"?'

 

Most of us have already used some BGP community policy to no-export some routes 
to some where.

On the majority of IXPs, and most of the Transit Providers, the very common 
community tell to route-servers and routers "Please do no-export these routes 
to that ASN" is:

 -> 0:

 

So we could say that this is a de-facto standard.

 

 

But the Policy equivalent to "Please, export these routes only to that ASN" is 
very varied on all the IXPs or Transit Providers.

 

 

With that said, now comes some questions:

1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or 
something like that, that would define 0: as "no-export-to" standard?

 

2 - What about reserving some 16-bits ASN to use : as 
"export-only-to" standard?

2.1 - Is important to be 16 bits, because with (RT) extended communities, any 
ASN on the planet could be the target of that policy.

2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 09:21, Robert Raszuk wrote:

> Nope .. it is the other way around.
>
> It is all easy if you look from your network centric view.
>
> But if I am connected to 10 ISPs in each POP I have to build 10
> different egress policies, each embedding custom policy, teach NOC to
> understand it etc...

Well, yes and no.

We, for example, connect to more than one transit provider in at least
one of our PoP's. The outbound policies are exactly the same. The only
difference is the differences in naming for each policy, and how we
signal RTBH into the transit network. Everything else is the same.

Rinse an repeat for all the exchange points we have connected to a
single router, in a single PoP.

I get that no two BGP routing policies are the same between operators,
but I'm not certain standardizing on communities is going to make things
any less complicated than we currently assume they are.


>
> I think if there is a defined way to express prepend N times to my ISP
> peers across all uplinks or lower local pref in my ISP network in a
> same way to group of ISPs I see the value.

These kinds of policies are generally do-and-forget. When you spend time
turning up a new provider, you are dedicating time to setting them up on
your end. An extra 3 minutes to configure communities they have
published is not overly complex, I believe. Moreover, it's not something
you are likely to revisit outside of a communicated change on their end,
or troubleshooting on your end.

I'm all for making many things as standard as possible, but if our goal
is to make signaling of external communities simpler than it is today, I
don't quite see how standardizing said communities will simplify that
process in a practical sense, on a global basis.

As always, I could be wrong...

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Mark Tinka via NANOG]

On 9/Sep/20 09:15, Robert Raszuk wrote:

> On last point yes. The entire idea behind flow spec is to work
> inter-as to mitigate DDoS as close to a source as possible.

Indeed, that is the original intention. Any reason why we don't see it
happening in this way, today?


> And as far as wide they just let you structure your community in a
> common way. It is both to customers or to others as you choose.
> Nothing there is about trust. It is all about mechanics how you pass
> embedded instructions.

Again, no technical or mechanical limitations at all with trying to get
this done. What I am saying is that the element of trust gets in the
way, for better or worse.

But while on the OP's intent - if you were to provide communities to
peers to signal forwarding in your network, you can simply publish those
communities on your web site. They don't need to follow any standard. At
the same time, if the industry were to agree on standard communities to
signal typical forwarding decisions within our networks, those would
work too, and I dare say that operators would publish them on their web
sites either way, for the avoidance of doubt. Moreover, anyone
implementing those communities would probably double-check with the
intended operator to make sure that what they are going to signal as
an-agreed global standard is supported and will work.

Just like how solar PV inverters are meant to disconnect from the grid
in the case of a utility outage, line workers will still, as a matter of
course, always check the line to see if it's live or not, before
performing any repairs. That line workers can simply trust that PV
inverters are doing the right thing in the event of a grid failure is
not practical. Checking to see if the line is live does not impose any
inconvenience on standard operating procedures.

So if we are able to provide support for remote signaling of forwarding
within our networks to off-net peers via communities, be it with
standard or dis-aggregated community values, either facility is
available and technically feasible today. The better question to ask
would be why this hasn't taken shape outside of provider-customer
relationships.

Mark.

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Robert Raszuk via NANOG]

Mark,

Nope .. it is the other way around.

It is all easy if you look from your network centric view.

But if I am connected to 10 ISPs in each POP I have to build 10 different
egress policies, each embedding custom policy, teach NOC to understand it
etc...

I think if there is a defined way to express prepend N times to my ISP
peers across all uplinks or lower local pref in my ISP network in a same
way to group of ISPs I see the value.

Best Regards,
R.


On Wed, Sep 9, 2020, 06:36 Mark Tinka via NANOG  wrote:

>
>
> On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
>
> Exactly Mike!
>
> The Idea would be to define some base levels, to make the creations of
> route-filtering simpler to everyone in the world.
> And what comes beyond that, is in charge of each autonomous system.
>
> It would make the scripting and templates easier and would avoid
> fat-fingers.
>
>
> Are we saying that what individual operators design for their own networks
> is "complicated", and that coalescing around a single "de facto" standard
> would simplify that?
>
> Mark.
>

Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'

[Robert Raszuk via NANOG]

Mark,

On last point yes. The entire idea behind flow spec is to work inter-as to
mitigate DDoS as close to a source as possible.

And if you validate against advertising reachability what's the problem ?

And as far as wide they just let you structure your community in a common
way. It is both to customers or to others as you choose. Nothing there is
about trust. It is all about mechanics how you pass embedded instructions.

Best,
R.






On Wed, Sep 9, 2020, 06:25 Mark Tinka  wrote:

>
>
> On 8/Sep/20 20:15, Robert Raszuk wrote:
>
> > This does not require any more trust for say directly connected peers
> > more then today when you publish communities on the web page.
>
> I'd tend to disagree.
>
> Trusting your direct peer to not send you default or to have a 24/7 NOC
> to handle connectivity issues is not the same level of trust I'd afford
> them to send me a community that told my network what to announce to my
> other eBGP neighbors or not.
>
> Of course, I am probably less trusting than most, so I'm not
> recommending anyone follow my advice :-).
>
>
> > It is not about opening up your network. It is about expressing your
> > policy in a common way in the exact say amount as you would open up
> > your network today.
>
> I can express my policy, publicly. But I can also indicate who has the
> power to implement that expression on my side.
>
>
> > Notice that in addition to common types there is equal amount of
> > space left for operator's define types. It is just that the structure
> > of community can take number of arguments used during execution -
> > that's all.
>
> That is all good and well, and works beautifully within an operator's
> network, which is the point of the capability.
>
> Extending that to non-customer networks is not technically impossible.
> It's just a question of trust.
>
> It's not unlike trusting your customers to send you FlowSpec
> instructions. No issues technically, but do you want to do it?
>
> Mark.
>
>