This is the meeting announce Etherpad for IDR IETF 107 Session B - 4/8/2020 at 13:00-15:00 UTC
[version 2]
WebEx: https://ietf.webex.com/webappng/sites/ietf/meeting/download/5FF4D33B273CA952E0536284FC0AC72E
Etherpad for note-taking: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-idr-02?useMonospaceFont=true
Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet
jabber: idr@jabbert.ietf.org
Scribes: Sue Hares, John Scudder, Jie Dong
1.Administrivia + Status 10 minutes
Status: Feedback on interims
2. BGP YANG Model Status and Issues
Draft: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08
Presenter: Mahesh Jethanandani
Time period: 10 minutes
John: Mahesh - you've answer the one question - when we will be ready for WG LC.
3. Presentations – new drafts or status updates
1) Flowspec for L2 and Tunneled Traffic
Draft: https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-13
https://tools.ietf.org/html/draft-ietf-idr-flowspec-nvo3-08
Presenter: Donald Eastlake
Time period: 20 minutes
Discussion:
John: Jeff Haas indicates he will review this draft as soon as he can.
Please provide comments as we heading toward WG LC and pseudo WG LC.
Donald: I welcome review.
2) BGP Well-known Large Communities
Draft: https://tools.ietf.org/html/draft-heitz-idr-wklc-00
Presenter: Jakob Heitz
Time period: 15 minutes
Discussion:
Jeff: When I was reading the draft, I did not
see comments about requesting the numbers from IANA.
One of the was 1997 was the that the top community,
was removed. The AS number fell out of use.
What your are covering out a set of AS numbers that
should get "magic" treatment.
Jakob: I have an IANA considerations for the range of
AS considerations.
Jeff: I see I missed the IANA considerations.
Jakob: As you do mention, this range is so big that
that is reasonable to carve 1/64 of the space.
Jeff: You have answered that you have made these
numbers special. People should reserved these
AS numbers in thir implementation.
Randy Bush: 67 million?
Jakob: Yes - this is a magic number.
Jeff: What happens to the AS path?
Jakov: It could be used in an AS Path.
Sriram: Essential Jeff is asking if these
AS numbers with well-known community arrive in an
AS Path, should you drop the update.
The answer is "yes".
Jeff: Think it is stronger than private ASNs. BGP implementations should drop these
automatically, rather than through configuration.
Randy: Dropping private AS are under operator control.
Did the proprogation from AS 1 to AS 2 is prevented by router,
and not operator control.
Jakob: This is a community.
Randy: Currently operator control indicates what is dropped.
Jakov: This is different.
John: Did you want to answer further?
Jakov: I've answered this I believe - the router drops it.
Rudieger: The turning a range of AS numbers into a metric
has semantics for redistribution, seems something
needs a lot of security. Everyone could be filtering
things with strange paths. The sematics of the metric numbers
(see Randy's remarks) is very tricky. You are talking about the
single hop change and the administrative domain.
The administrative domain is more fragile because the
concept of adminstrative domain is not defined.
If each router has to determine what the administrative
domain, you will have route leakage because
the edge routers of administrative domain
needs to be aligned.
This needs lots of scruntiny, and a description
of what the
Jakov: Thank for your comment. The
administrative domain needs to be configured on both sides
of the administrative domain. I do not see where this
concept is difficult. This determination could be
done in the router code rather than the policy.
You could be done
Rudieger: What ever is done in the router code
needs to be some configuration in the policy code.
Jakob: The router needs configuration.
Do you mean you need coordinated configuration on
both administrative domain to make it work?
Jakob: yes.
Rudiger: How realistic is this that all edge routers are
consistently configured? This is difficult already.
To add to this problem, adding remote AS be consistent
is not difficult.
Jakob: I see that it is very easy to do.
This is not a big challenge.
It has to be configured for all routers
inside the administrative domain.
It only needs to be consistent within the domain
but not across the domain.
Rudiger: You can only make use of this feature after you
configure all the domains. I would then need to
make sure all my vendors add this code before adding this code.
[pause]
Adding the domains for transitivity from specific router
functions to identify the router domains.
Regarding what happens if the magic numbers appears in AS_PATH, my answer is no need to deal with it for now. But for long term it may
Jakov: IANA does have ranges that are new and used.
I've picked a
Rudiger: There is the delegated NRO register - that indicates
which AS are actually used. I presented statistics regarding
this at one of the IDR/SIDROPS meetings.
Jakob: To summarize you indicated that these numbers will
not cause a problem.
Rudiger: You assign a range to IANA that is not used.
The secondary order is the loading of the AS number with
semantics.
Jakov: I think this is reasonable.
Rudiger: I'm done for now.
Jay Borenhagen: RFC8642 for those who writing (large, communities, )
RFC should specify how the large attribute is to be handled.
Jakob: Thank you for the RFC number. I take another look
Yunan Gu: I small suggestion not specific to this draft but
RFC8092. Should this RFC8092 be updated to handle regarding the handling
of Reserved ASNs be handed to the RFC. It should covered
the question that Jeff raised what happens if this is covered in the
AS Path.
Rudieger: The philosophy behind the Large communities to
be free of semantics for everyone. Jakob suggestions to
create number ranges with semantics is contrary to the
current large community specification.
Yunan Gu: If we establish a range, it should update RFC8092.
If not, we do not update RFC8092.
Rudieger: Asking for a range is quite different than
the current structure has only administrative range.
This is a fundamental change and goes far beyond
just asking for the large communities.
Jakob: I do agree with you that this is a change.
I feel the reprocussions (sp) regarding this range.
Rudieger: I believe Jay's pointer is pointing at this
problem. I can explain an alternate solution offline.
Jakov: I think we could further discuss this on the list.
Randy: Jay is saying what must be specified to the author.
Reducing what the operator
you must specify: what happens in the AS path,
what happens in the allocation process, and
what happens in incremental deployment.
Jakob: I will take the answers to Randy's question to the list.
Jie Dong: My first point was raised by Rudeiger, Randy and Jeff. What to do if the reserved ASNs appears in AS_PATH or other places.
It should be clarified in the document.
Jakov: I will add this to the draft.
Jie Dong: I agree with Rudieger that this change is more than
just reserving some ASNs, it introduces a new format and structure to large community.
Jakob: Can you bring to the list the exact problem
that this will call? Bring the actual problem to the list.
Jie Dong: We may need to revisit the design principles of the
community, extended community or large community, wide community. Taking the pros and cons into account.
We could then make the structure an the impact of
the transitivity.
John: Any further comments? No
Jakob: I could clear up interactions, but I do not
think the larger design and
Sriram: We are talking about a request for
a large community registry. We thought this might be
fast track.
John: In having a large registry, we need to something
that has structure.
Most of discussion is about transitivity. Suggest to take this controversial part out.
I do not see hope for moving registry.
Jeff: To sriram's is to consider to use a single AS number,
then you just need to reserve the single number.
If you have
Susan: Suggest to have a registry of one or two reserved numbers.
Sriram: Is large community considerted transitive?
Jakob: It is transitive:
Rudiger: I very much Sue's point. I would also like to
make a remark that that Sriram use case is something
well-defined and very specific. Jakob draft does
not provide explanation for the well-known communities
for what needs to change in the router implementadefinitions or
the policy definitions. Going for a few numbers does not
go into the larger.
Jakov: This is a framework in which to put these
numbers into.
Rudiger: You need to add to the draft to add the
semantics on the router
At Irish Dublins IDR has figured out that this
was not possible. The environment has gotten more complex
over the last few years. The semantics needs to be
carefully defined - to be determined if the
regular communities or the
Jakob: This is like the 65535 number. This is a framework
to help this specific.
Rudiger: you would need to make this explicit.
And you will need to make explicit.
Jakob: An example would be the blackhole community where
it must be programmed in the operators.
I am asking for a range.
John Heasley: You have 4 byte ASNs and a additional space.
Given one community value you have the ability to have
two ASNs and a value to specify the value.
You are reducing the name space by adopting Rudiger's suggestion.
John Scudder: Individual contributor hat.
I will skip over my "nit-picking" specification.
The authors felt the large communities that the should not introduce additional semantics.
fancy encoding. As one of the early propoents, what changed?
Jakob: John and Sriram came up with uses that wanted to use
an ASN attribute. These seems like an easy way to
accomplished this action.
John: Ok. Water under the bridge if we did not see what we needed then.
The transitivity seems a little odd to apply it to just one
path attribute. This feels to me like something that needs to generated.
Jakob: I know there was a draft to have all future
attributes should have transitivity. This draft did not go forward.
I think I would try this in a restrictive path rather than the general case.
Since there was many operators who want to share within a administrative
domain.
[Chair hat on]
3) BGP Community Reserach:
presenter: Randy Bush
paper: https://archive.psg.com/181101.imc-communities.pdf
Time period:15 minutes
Warren: I agree this is a bad issue.
If the attacker did not announce, still an attack.
Tony P: You give folks an unlimited crayon box, what you
expect. If you kill unlimited distribution, it would
be cheaper to go AS to AS.
Randy: Shutting down the transitivity will help.
Community - does not have any attributes.
Cutting down the airflow will help, but it is still garbage.
Rudieger: One thing in one part, we have all these
communities and we do not know the semantics.
Actually, getting to a situation where we would get to
documentation about what is floating around
is a few years. Determining how we might
document the communities metric strings
might by assembling.
Randy: Good documentations and structuring
would help the problem. Giving the world
increasing the attacks and the need for the
Internet is increasing -- this will be challenging.
Rudieger: We need face mask in both directions
the air that we inhale between ASes.
In BGP terms, we need to minimized what
is not authententic. We can only trust
our neighbor who is wearing a mask,
and trust what we send if we are wearing a mask.
CIDR is an example of this point.
Spreading prefixes with EBGP you should
consider you are spreading the viral
infection unless you have protection.
We have to actually get a little closer to
a mask.
Randy: I would be surprised if anyone disagrees with you.
Jeff: I'm' going to change what I was going to
say and only build on Rudieger.
What we need to have hygiene.
Some opertors are very careful regarding their hygiene.
As vendors, our policy for communities is funky
and it is difficult
Randy: I agree, but I think a little wider.
There is little a little wider, do not put
active semantics in communities.
If you do, please put a formal description
because some day we will design a better bgp security.
Attribute will be signed.
Do not put active attribute in communities,.
Jeff: It is well understood that this is your opinion.
In the non-Internet situation, the commnities are usef
Randy: Did you overstate my opinion?
Rudieger: Attacking the documentation aspect would
provide a basis for generating better filters.
I am not convinced the traditional vendors policy
languaged will provide easy ways to draw in
information from a document base.
The document could be done by generating
(?automatically) the documentation.
Randy: Documentations will be helpful.
[comment on flow specification].
Warren: Thank you this is an important , the question is why discuss this in IDR?
Sue: This is pros and cons discussion about the proposals.
The purpose is to have the discussion we have now about community.
Warren: My question is about how to move forward.
Randy: Sue
Rudieger: Randy's asking for cryptographic signed attributes.
Looking at stuff that goes in direction.
Looking at things that have a chance on a shorter timeline
goes into different topics. What types of filter specifications.
We need to do both.
Randy: no one is disagreeing.
4) Discussion time on Communities: 15 minutes
5) BGP Extended Community Registries Update
Draft: https://tools.ietf.org/html/draft-cl-idr-bgp-ext-com-registry-update-00
Presenter: Christoph Loibl
Time period: 10 minutes
Sue: This comes from Alvaro's review so it is a bit of necessary clean-up.
I will be posting a WG adoption call after I finish IPR query.
Total time: 2:10 minutes
Etherpad for virtual blue sheet:https://etherpad.ietf.org:9009/p/notes-ietf-107-idr-2-bluesheet