Minutes IETF108: idr
minutes-108-idr-02

# IDR meeting at IETF 108

## Friday,  14:10-15:50 UTC, July 31, 2020

### Materials:
  https://datatracker.ietf.org/meeting/108/session/idr/

### Meetecho:
  http://www.meetecho.com/ietf108/idr/

### Collaborate on Note Taking：
  https://codimd.ietf.org/notes-ietf-108-idr/  (recommended)
  https://etherpad.ietf.org:9009/p/notes-ietf-108-idr/


### 0. Agenda bashing and Chair's slides (10 mins)
Requests for WG LC and WG adoptions will be sent
to the idr list after the meeting.
Check it.

### 1. RD based ORF [Wei Wang/Aijun Wang] (10 mins)
  https://tools.ietf.org/html/draft-wang-idr-rd-orf/
Wei Wang presenting.
praveen Mada: I have a single domain case I want to ask a question regarding.

When PE1 injects a prefix, will it impact other routers which are not overflowing the source?
Wei Wang: The RR will check the IP source address, and it will not send to PE2 and PE4.
Praveen Mada: It would be useful to provide more detail
on the use cases in the draft.  Do you
have any implementation experience with this draft?

Wei Wang: I cannot hear the question.

John Scudder: Please take the questions to the list to
regarding the use case and the implementation experience.

Keyur Patel: The back-pressure to the PE may not be
required.  The prefix filter level filtering has
more expense than a higher level filters.
[Robert Razuk (chat list)]: An RD-ORF
there was a number of technical problems
sent to the list. None of these were addressed.
This is not the right way to filter VPN.


### 2. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins)
  https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/
Giuseppe presenting.

WG adoption requested.
[no questions]
[from chat]: [Ketan Talaulikar]: Having a routing/control plane considerations of
IFIT proposal in some document would help.
Right now it is being introduced in
multiple protocols, but I'm not getting
a proper picture. Please point to any document
that I am missing.
Giuseppe: Good point
 @Ketan good point we will give a proper picture in the next revision.
Ketan Talaulikar
@ Giuseppe. Thanks. Would really appreciate a sort of routing consideration
section in your base IFIT document that puts out requirements for all these
various routing protocols that you are proposing to add IFIT extensions to.
It would make it easier for review.10:49:04
Giuseppe Fioccola: @Ketan A new section in the beginning of the draft
can help to clarify. We will work on that10:59:10


Joel: Hmm. I thought the ifit proposal in other WGs was distinct from the
ioam and alternatve marking proposals.10:26:32]
Giuseppe:   Joel yes in other documents IFIT is also associated with the framework
 but in this document we just use IFIT acronym as "In situ Flow Information Telemtry"
 to summarize in one word IOAM and Alt Mark methods.
 @Giuseppe - given the different use of the term, I find it confusing to use
 it in this draft to mean "these two other things".
 @Giuseppe - depending upon how the draft evolves, the term may well become
 irrelevant. In which case it is not needed.

 [end chat]



### 3. BGP Bitmask Route Target and RT-Constrain Extension [Jeffrey Zhang] (15 mins)
  https://tools.ietf.org/html/draft-zzhang-idr-bitmask-route-target/
 https://tools.ietf.org/html/draft-zzhang-idr-bgp-rt-constrains-extension/
Jeffrey Zhang presenting..
Jie Dong: First comment on the bit mask route target.
Is it main use matching the group defined in teas.
Jeffrey: yes, this is the use case.
Jie Dong: We had another draft describing the
generalized RTC which was not adopted.
The draft-ietf-idr-bgp-ipv6-rt-constrain has
a mechanism to allow for this.
Jeffrey: The global administrator could be an
IP address.
Jie Dong: If the global administrator could be a
prefix, and that would be a issue.

Haibo: Why not use a (not heard) prefix?
The receiver which receives the routes.

Jeffrey: I will need follow up online.
[from chat room]
Jeff Haas: Please repost the general rtc draft name?
Jie, Juniper's implementation of rtc-c allows for
short than host length for rtc filtring.
Haibo: rt-c RFC4684 is applied to many address families.
This extension works in similarly address family agnostic fashion.
Jie: http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02.txt
Jeff: Thank you Jie. I recall reviewing at the time.
I'll re-review for applicability to our problem.
Jie: Another question is can the BIT mask RT
be advertised in RTC as prefix?
Jeff: Jie, there's still some encoding discussions happening
with the authors about how a wide community rt-c would look,
even for a dense case like we have in the proposed draft.
Jeffrey Haas:  Please expect us to followup the list on that point, Jie.

Haibo Wang: @Jeff, Yes, RFC4684 is applied to many address families,
but I don't think it's a good idea. If we want to extension the
RTC, why not we may set AFI to resolve the problem like Jie has shown.
Jeffrey Haas: Haibo, this discussion point covers a portion of what we had with the
draft Jie had posted moments ago. We don't currently segregate route
target types to specific vpn technologies.10:47:32
Haibo Wang: My another comments is that, whether should we to do it
like RTC or like RFC7543 CP-ORF10:48:05


Robert: RFC4684 does not allow to send RT as a prefix.
NLRI says fixed 8 octets. I proposed to the
authors addition of RT as a variable length
prefix as well - but that was not mentioned
during the presentation.
Jeff:  Your memory for rfc4684 is incorrect, Robert.
"The NLRI field in the MP_REACH_NLRI and
MP_UNREACH_NLRI is a prefix 0 to 96 bits,
encoded as defined in section 4 of [5]."
Robert Razuk:  Clearly RTC ... ORF is not transitive.
RFC7543
Robert Raszuk: @Jeff - yes I take it back ...
I was thinking about SAFI 128 not RTC10:52:09

Jeffrey Haas: It's okay, Robert. We keep repeating that point about
RFC4684, so it's clear that it's in people's heads as being
fixed length for some reason.10:53:44
Robert Raszuk: Probably as RFC does not show length field in the figure :)10:55:17
and figure says 8 bytes not 0-8 bytes too10:55:45
Jeffrey Haas:  That would make sense, Robert. That may be worth an errata.10:56:12
Robert Raszuk: Agree.10:56:29


Bill Fenner: @jhaas in fact I had to fix tcpdump for that case too10:54:14
Jeffrey Haas: !Bill, probably because of our implementation. :-)10:54:30



[end chat room]

### 4. BGP-LS with Multi-topology for SR based VTN [Cong Li/Jie Dong] (10 mins)
  https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt/
(Cong Li presenting)

[chat room start (not sure if this is the correct link]
Ketan Talaulikar: I'll post my comment here to save time.
BGP-LS has been specified as a northbound
distribution mechanism for topology information from
network to controllers.  One of these drafts is
proposing to re-purpose BGP-LS for southbound
provisioning.  Leaving aside whethr BGP
is suitable for this, why not consider doing this as a
separate Conficg SAFI?

Floor questinos:
Zhaohui Zhang: Can we chat about scalability.
The Bit mask route target has ways to reduce the flow.

Jie: We have some BGP based mechanisms regarding this
topic.  We can talk about this more on the list.


### 5.Traffic Steering using BGP Flowspec with SRv6 Policy [Yisong Liu] (10 mins)
  https://tools.ietf.org/html/draft-jiang-idr-ts-flowspec-srv6-policy/
[Jeff]: As an author of the redirect IP draft,
since you are specifying more than one community
you need to be careful how this interactions.
[Kaliraj Vairavakkalai]: How does this work with the
inter-domain case?
[Yisong]: We'll consider this information in
future drafts.


### 6. BGP-LS Extensions for Advertising Path MTU [Yongqing Zhu/Shuping Peng] (10 mins)
  https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
(Shuping Peng presenting)
WG Adoption called for by authors.

Ketan: The draft is a trill draft that describes RFC7176.
[missing the response from shuping so notes get text from Shuping]
Ketan: Thank you for the clarification

Jeffrey Haas: Shuping, with regard to the link MTU draft, I think it's a useful feature.
However, I would suggest the document provide a warning that this is the
signaled MTU which may be different in bad cases from the actual MTU.
this is usually from configuration mismatches in a control plane and
a data plane component.11:04:57


Tom Hill: +1 Jeffrey & Ketan - there are many "MTUs"11:06:25
It is otherwise not a bad idea11:06:49
Jeffrey Haas: IMO, having a way for probed MTU to be published
in bgp-ls is a nice feature.11:06:52
but since once of the pathological cases is
LAG with mismatched MTU component links...11:07:18

Takuya Miyasaka: The title of this document is confusing.
I think it should be [BGP-LS Extensions for Advertising "Link" MTU]. 11:08. 11;

Shuping Peng
@Jeffrey, thank you for the comments. Your concern is acknowledged
and we plan to add it in the next version.11:12:07

Alvaro Retana: @Ketan: The registry shows that the sub-TLV applies
to the "normal" TLVs: 22, 23, etc.. It seems to me that we should be
ok.11:12:10

Ketan Talaulikar: @ Alvaro : yes we should ok


### 7. BGP Classful Transport Planes [Kaliraj Vairavakkalai] (15 mins)
  https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes/
  (kaliraj Vairavakkalai presenting)

  Robert Razuk: Today transport class can be embedded in the SID.
  Here we are opening it up to explicit signalling ... I understand
  you may want to support RSVP TE but not sure if this
  extra complexity is really needed.
  (read by Sue)

  [chat room:
  Jeffrey Haas: Robert, while it can cover such a scenario, this draft
  supplants the problems we were trying to solve in the prior
  labeled-color-unicast draft.11:21:09
   So, a degree of similar flexibility is desired.11:21:19

  Robert: @Jeff: I like the new SAFI sepration if we go for that ..
  I recall the BGP 3107 discussions about it too. Just not sure we
  still need it if we are up to SR everywhere paradigm

  Kaliraj: Works with other deployed technologies for
  tunnels we have. It is good to have a layer which
  I'm not sure if you are referring to
  Jie Dong: Policy has a color and and nlri.
  Are you transferring color as a SR-TE tunnels?
  [Kaliraj]: The color is the transport color of that
  tunnel.  We will create a transport class with
  a color so that it fits seamless into the SR-TE tunnel.
  [scribed missed a portion of text]

  [Jie Dong]: I will take up more on this topic online.


### 8. (If time allows) Controller Based BGP Multicast Signaling [Jeffrey Zhang] (5 mins)
  https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller/
   John: By the careful help of the presenters and
    by some miracle we have time for the last presentation.
  (Jeffrey Zhang presenting)
  [request early allocation for the code points ]
  John Scudder: The "any encap" would you be able to
   use a multiple next hop mechanism in BGP.
   The controller want you to replicate across 2 tunnels.

   Jeffrey: For one down stream ways to get to a down
     stream node, go through any of the 20 tunnels.

   John: If we had a way to represent 20 next hops,
    you would have used it (observation).
    The load balancing tunnel is not limited to multicast.

  Jeffrey: The load balancing concept introduced for
   multicast purpose. There seems to be an existing
   tunnel for the load-balancing of unicast.
    [missing a portion of the discussion.

John: The programming incoming packet handling.
   The whole model that tunnel-encaps used is that
   you send information regarding the head of the tunnel.
   Your drafts talk about the tail of the tunnel.

Jeffrey: Can you provide a bit more information on the
 tail end?

 John: ingress is head ends, and egress is tail end.

 Jeffrey: The route sent to all points.  For the route
  sent to the egress point, it is for the

 Kaliraj: This is a reserved layer.

 Jeffrey: This gets to beyond the tunnel encapsulation draft.
 We are talking about controller signaling.
 Every router will use the same label.  That
 label will be assigned by a controller.

 Kaliraj: Like from a static route configuration.
  To John, we did propose multiple next hops for a bGP route.

  Jeffrey: Could we use tunnel encapsulation instead of
  multiple next hops.

  Kaliraj: This draft is giving a specific tunnel endpoint.
  Your draft is slightly different.




### 9. WG adoption calls requested

  https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/
  https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/

###
#### [5 minutes for switching]