13:00 - 15:00 (GMT+10) Monday session II
Room: M3
Agenda bashing and Chairs' Slides (10 mins)
[Chairs]
Generic Metric for the AIGP attribute (10 mins)
draft-ssangli-idr-bgp-generic-metric-aigp-07
[Srihari Sangli]
Jeff Haas: Due to limit time, can only have one brief question.
No question in the room.
Susan: I sent some comments to the list.
Jeff Haas: One question from our AD, why does it belong to IDR rather
than BESS?
Chongfeng: This can be discussed on the mail list.
Susan: Do you have implementation plan of the Segment Types extensions
for BGP SR Policy?
Yao: Currently no implementations of the segment types in this draft,
e.g. segment type G. There is ongoing implemenations of the Segment
Types in the SR Policy WG documents.
Susan: Please share the information to the list, thanks.
Jeff: L2 bunble members are incosistently addressable in different
implementations. Do you consider to make this a general feature.
Mengxiao: Will think about it.
Ketan: The addressability of L2 bundle member is using local and remote
IDs, that information is sourced from IGP,
Jeff: My question was about the forwarding behaviors of bundle, which
was left up to implementations by IEEE.
Ketan: The use case is to steer over a specific bundle member, bypassing
the load balancing behavior of L2 bundle.
Sue: Before adoption, if you update other RFCs, need to put that into
the header of your draft.
Jie: After a quick review of RFC9085 and 9086, it seems Adj-SIDs can be
carried as a sub-TLV of L2 bundle member attribute TLV? Is it already
defined there?
Mengxiao: It cannot be carried as sub-TLV, as it is in the link NLRI.
(from chat)
Jie: @Mengxiao Just double check the specs, currently PeerAdj SID is not
included in the L2 bundle member TLV, while Adj SID can, do you think
that is not good enough?
Changwang Lin: @jie dong: peer adj sid can not be the sub tlv of l2
buundle member tlv
Changwang Lin: this draft reuses the peer adj sid tlv as sub tlv of l2
bundle member tlv
Jie: @Changwang what I mean is can adj-SID be used instead of peer-adj?
Ketan: @Jie, AdjSID is for IGPs and we are talking about a BGP EPE
PeerAdj SID ... semantics are slightly different. You will note we are
not adding new TLVs - just updating procedures to cover BGP EPE for L2
bundle members
Jie: @Ketan I see the difference between adj-SID and peer-adj SID, then
what about SRv6, do we need a different SID type for BGP links?
Mengxiao: @Jie Section 4.2 of RFC8986 specified that End.X can be
allocated to L2 bundle members.
Jie: @Mengxiao End.X was for IGP, my question is do we need a new type
for l2bundle in BGP EPE? Better make is consistent between SR-MPLS and
SRv6
Mengxiao: @Jie End.X can be used for BGP EPE, also specified by RFC8986.
For MPLS-SR, we reuse the existing PeerAdj SID TLV. In SRv6, we use
End.X SID TLV. I think it is consistent. :)
Jie: @mengxiao chen, I see the text in RFC 8986, thanks. So it is due to
the approaches for EPE in SR-MPLS and SRv6 are different.
No comments.
Ketan: Is there supporting document about the applicability of SR Policy
with NRP?
Robin: This is about protocol extension. What is required from SPRING
WG?
Jeff Haas: For the BGP-LS extensions which are used for features defined
in other WGs, IDR needs to make sure the base work is active and making
progress.
Robin: This is related to network slicing, which belongs to TEAS.
Jeff: IDR chairs have regular syncup with TEAS on the NRP related stuff.
Susan: Suggest the authors to check with TEAS about their opinions on
this document.
Susan: Regarding the information does not fit into a single BGP update,
it is about the old max message length.
Jie: Yes, it is not about the BGP extended message. As in some networks
it is not supported yet.
Keyur: Flex-Algo allows you to slice a network. Does this mechanism work
in conjunction with Flex-Algo, or is it to aid Flex-Algo, or is it to
work in scenarios where Flex-Algo is not present.
Jie: Good question. Flex-Algo can work with this mechanism. We may have
a few Flex-Algos, while more NRPs, then some NRPs can be associated with
the same Flex-Algo for topology and path computation, while each NRP can
havce its own resource attributes.
Keyur: Is it to aid Flex-Algo by giving more data from the network to
Flex-Algo?
Jie: It is not to aid Felx-Algo with more data, Flex-Algo is for
distributed path computation, this information is advertised to the
controller for NRP specific constraint path computation. They are
complementary.
Ketan: Is this NRP information sourced from IGP to BGP-LS?
Jie: It may be source from IGP or from local configuration.
Ketan: If they are sourced locally, need to be careful about source
local configurations into BGP-LS. Need to draw a line about what
information needs to be sourced into BGP-LS.
Jie: Understood. There is also other local information sourced into
BGP-LS. If the information is used for path computation, BGP-LS would be
the right tool.
Keyur: Suggest to clarify what information needs to be sourced and why,
so as to avoid circular dependencies.
Andrew Alston: Confused. After multiple BoFs APN is not fully defined.
Are we jumping the gun by bringing something like this into IDR? Is this
too early?
Shuping Peng: The technology of APN is solid. The use cases and
deployments are documented in drafts, and there is a side meeting on
this.
Robin Li: The APN use cases have been widely accepted sinc the APN side
meeting. We will communicate with AD and Chairs to see whether we should
do the protocol work in relevant WGs instead of having a specific WG.
Andrew: We need to be careful when there is no IETF consensus to
proceed.
Jeff Haas: The discussion about the encoding is helpful for
understanding APN. But this document will not be adopted before there is
support of its base technology.
Dongyu: What would be the appropriate granularity of the Flowspec rules?
Is there different use cases of deseminate APN rules to the mid points
and the headend nodes.
Shuping: The granularity depends on how you determine it at the edge of
the APN domain. The length of the APN ID depends on operators use case.
Jeff Haas: The ording of normal Flowspec filtering components are based
on the component IDs. Flowspec v2 allowss to define different order.
There is discussion about hwow to allow for more fine grain ordering.
The ordering of group and sub-group may introduce additional complexity.
Shuping: Think the current solution is efficient, but can discuss more.
Sue: Flowspec v2 is working on the ordering of actions, we are
considering wide communities. We need to discuss the pros and cons.
Xuesong: Glad to see APN related protocol extensions are discussed in
the WG. We will have an APN side meeting this week. Welcome to join us.
Robin Li: There will be introduction of APN use cases and deployments on
the side meeting.
Keyur: The draft is pretty light. Please add more information about the
rule sets. No.1, the rules of inserting of AS number in the middle.
No.2, need to explain what happens when the keys are refreshed.
Susan: Need to prove that it is equivalently secure as BGPSec.
XXX: What would be the impacts to FIB or RIB size, memory comsumption
and convergence time, etc? Will the update to BGP path selection cause
some issues with legacy nodes?
Zhuotao: Suggest to do stratigic deployment on the capable nodes. Legacy
nodes will ignore the FC attribute and do normal path selection.
Jeff Haas: Changing BGP route selection brings dangers. Inconsistent
path selection in one AS will cause loops.
Nan Geng: Where do you implement FC-BGP? Based on open source?
Zhuotao: It is based on Quagga.
Nan Geng: About path selection. Why not use the same path selection as
ROV?
Zhuotao： Good suggestion, will talk more offline:
Maria Matejka: Does this disable the router server transparency?
Keyur: For overlay BGP path, how does a router know the underlay path is
hijacked?
Zhuotao: The overlay is just for testing in current stage.
Jeff: My second comments is you are leaking the attributes into the
outside world.
Tom Strickx: It seems relies on RPKI. If RPKI session fails, can the BGP
session maintain up?
Destination-IP-Community Filter for BGP Flow Specification (10 mins)
draft-wu-idr-flowspec-dip-community-filter-00
[Tianhao Wu]
Susan Hares: You are proposing filtering based on BGP commmunity rather
than fields in packets? How is this acheived in forwarding plane?
Tianhao Wu: BGP community needs to be added into FIB, so that it can be
used as filters.
Jeff Haas: The instability of community has been addressed. Another
question is filtering based on BGP route attributes. If you have
flowspec states generated from RIB, you need to generate the same amount
of flowspec states as in the RIB. In some cases the amount of flowspec
filters based on community may be large, and it may be out of control.
Tianhao Wu: We should limit the number of the BGP community filters.
Jeff Haas: Please take that into consideration and do some scale
analysis.
Ketan: The resource for ACL in forwarding plane is limited. BGP flowspec
was for DDoS. You can put limit on the number of rules. The idea is
good, while have concerns about how it is done.
Keyur: The rules are generated by controller or routers? Can it be
generated inline (by the router)? Then you don't need this extension.
Nan Geng: It provides one method.
Jeff Haas: There are multiple ways to provide the function.Can the
VRFmode be tied together with the Flowspec mode? The interface set is
not in NLRI as the interface IDs are scoped to a single AS. For savnet
we need to look at the multi-AS case.
Susan: Flowspec interface set as filters and actions will be worked in
this WG.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 105 minutes
13:00 - 15:00 (GMT+10) Friday session II
Room: P1
Sue: Will add the draft into WG LC.
Jeff Haas: People at Juniper are keen on contributing, and probably
similar for other vendors. But not obvious which WGs things belong to,
e.g. sidrops. ADs and chairs will discuss, particularly whether the
document can be kept as one or should be split.
Sue: Thank you for the hard work on YANG model.
Ketan Talaulikar: (for chairs?) this was related to cats, what happened
there?
Jeff Haas: This work predates cats; there is overlap but it's still
within charter for idr.
Linda: If CATs requries new path attribute, do they need to come to IDR
for approval or they can create a new one？
Susan：Path attributes and BGP mechanisms need to come to IDR.
Ketan: It is lose or open about what can be carried in this attribute
now or the future. Can we use it for anything and everything? Better to
have a proper scope.
Linda: This has to be discussed in IDR.
Jeff Haas: If cats needs this attribute in future, it can be reused and
extended.
John Scudder: It is not clear whether CATs would need this or not. As
for the extensions, without clear applicability and pricinples, there
will be some problems to move it forward.
Sue: Please provide comments and suggestions about its use.
Jeff Haas: Thanks for the presentation. The previous work stalled for
two reasons, one is Flowspec v2, another is personal reason. This work
is valuable and should be continued.
Susan Hares: Thanks for the presentation.
(Jeff went through the previous presentation of payload match)
Jeff Haas: The complexity we are looking at in Flowspec V2 is in the
different implementations of different subset of the filters.
Susan: Welcome to join the Flowspec V2 design teams.