Minutes IETF100: idr
minutes-100-idr-00

IDR meeting at IETF 100 (version 1)

13:30-15:30 pm,  11/13/2017
Room: Canning

Sue Hares: Starting in 2 minutes. Looking for note takers.

Chair's administrivia [13:30-13:45]
0) Agenda bashing and Chair's slides (5)

Sue: Starting the IDR meeting. We are meeting once this time. We do not have a
really packed agenda this time. There is a Note Well. You may have read this
before, please read it again. Note Well applies to anything that is said at the
mike is covered by it. RFC 5378 and RFC8179 has the details of what is covered
and how. We had a hiccup in our WG process a while ago - it was a late IPR
disclosure. Sue: Agenda bashing. John is not here this week. Jie Dong is IDR
secretary helping me to run the meeting. Ignas is kindly providing scribing.
First part of chair¡¯s slides: get all the drafts that were asked for be sent
forward, please check if we missed anything. Then we will go through the IPR
because we had a late disclosure. Then we will go through the existing drafts
and the new works. Sue: Comments on the agenda?

1) Chair¡¯s comments on IPR (10)
Sue: Going through the basic IPR rules and problem case. WG chairs tend to
trust the WG participants, and we would like to continue to trust. RFC8179
describes IPR disclosure rules. There may be sanctions for improper IPR
disclosure, including removing the authors from the document and/or taking
document off the standards track. ORR document had late IPR disclosure. We
asked on the mailing list whether this is a problem, and there were no
responses. If you think this is a problem come up to us and talk about it. IDR
WG does IPR poll in parallel to LC poll. We would like to continue with this
practice as it saves time. Does anyone have any concerns with this draft? No
response in room.

Updates on existing drafts [13:45-14:15]

2) Signaling ERLD using BGP-LS [Gunter Van de Velde] (10)
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld/

Gunter presenting.

[presentation]
When create this draft, the assumption is the main use case is for entropy
label. Over time there may be other use cases of RLD.        Would like to know
whether should put ELC and RLD together or separate in BGP signaling.
[discussion]

Jeff Tantsura : Initial use case was entropy labels. There are other ones that
would require multiple labels pushed and swapped on the transport, it is
important to know how deep the stack can go. It is not only related to PCE.
Jeff Tantsura : To confirm - you have a preference to confirm how many labels
can be used, not necessary specifying whether it is for entropy of something
else? Jeff Tantsura : It is for the operator to decide. It is essential to have
this information but not the detailed usage. There are limited capabilities in
microcode, it is up to operator to decode how to use it. Gunter: You can
actually signal the readable space but at the same time you signal the
capability of the router to do something with it, to actually use for entropy,
for passive marking, or for something which maybe not being documented yet.
Jeff Tantsura: In most cases it is agnostic. What it does is less important
than maximum depth. Stephane Litkowski: Speaking as coauthor of SPRING draft.
Based on discussion in Chicago we concluded that the RLD notion is not enough,
we did not have the knowledge on the ability of the router to read the entropy
labels. There needs to be a capability to read the amount of labels. In the
MPLS document we do not need any additional capability as it is included in
ERLD definition. In my opinion IGP draft should be consistent with this
approach too. Gunter: This is to be added in future. Stephane: In the future we
may see other uses of entropy labels. Jon Mitchell: In SPRING context,
intelligent TE does not require the use of entropy labels but would have a use
for RLD depth on a platform for a controller to make decisions. Gunter: Do you
mean separate or single? Jon Mitchell: Separate. Gunter: I have just heard two
completely opposite opinions. Jeff Tantsura: I forgot the question. :-) Gunter:
Interesting, I have heard two different positions here and not certain how to
progress, asking chairs for guidance. Jeff Tantsura: You should be following
the IGP, not invent your own. Stephane Litkowski: I agree, we need this
consistency between IGP and BGP, and this needs to be defined in MPLS document.
This needs to be addressed by MPLS WG. Chris Bowers: I agree to let IGPs to
address this. The logic should be the same as in IGPs. Sue: My personal
preference would be follow what IGP did,  and double check on the mailing list.
Ketan Talaulikar/Cisco: Label depth of MSD subtypes instead of separate type?
There is MSD draft. Do we use the same as a subtype? Gunter: No, we decided to
keep them separate. Chris Bowers: Can you repeat the conclusion what you
decided to do? Sue: My personal opinion is BGP should follow the IGPs. How to
get input - float this on the mailing list. Chris Bowers: You are asking about
adoption? Sue: Gunter was asking about WG LC. Chris Bowers: Therefore I believe
the conclusion is wrong. It should sit and wait until MPLS and IGPs figure out
what to do. Gunter: This is not the only draft following this recommendation.
There are BGP-LS documents that are used to export IGP attributes. Chris
Bowers: You asked for opinion. Stephane said it is in the state of flux. My
opinion the document should wait until it is solidified in MPLS and IGPs. Sue:
Do you know how long is the wait? Chris Bowers: No Jeff Tantsura: The relevant
IGP authors are in the room. Jeff Tantsura: Talking as MSD author, we created
separate IANA registry. Rather than use a separate registry, it could be a
separate subtype. Stephane: MPLS document was in WGLC that failed. We fixed all
the issues, I expect new WGLC to be sent. Maybe it is a good timing to ensure
that there is a WG consensus on IGP document. Sue: Is there anyone in the room
from OSPF or ISIS WG? Sue: Thank you for the input, it was very useful.

3) Carry Congestion Status in BGP Community [Zhenqiang Li] (10)
 https://tools.ietf.org/html/draft-li-idr-congestion-status-extended-community/

Zhenqiang presenting.

[presentation]

[discussion]
Robert Raszuk/Bloomberg: How do you plan to deal with the case on n links
between a pair of ASBRs, and the utilization on the links is different because
the hashing is not good. L3 links, not LAG. Zhenqiang: I think you are
describing the case of loopback peering, the sessions could be separated per
link (paraphrase of response). Jie Dong: This solution works for traffic
steering among different BGP peers, for the case of multiple links belonging to
the same BGP session, currently it is not covered. Ruediger Volk/DT: The
description of the semantics of this are sufficient. The idea of having
indication of load and congestion on several paths to be an important input for
routing decisions is clear, but when one defines a specific coding scheme to
signal that, the idea of how to derive the actual signal (that is partially
done in the draft) and what to do when you see the signaling - that needs to be
defined. The considerations on oscillation are in that territory. But it
doesn't look like the draft has anything that can prove that oscillation can be
avoided, rather let's see and observe and then fix implementation and
configuration aspects. In the complex interworking of BGP systems that does not
look like a convincing approach, although I have to admit it has been taken in
a past. Sue: Can you post those examples to the list to get more feedback? To
hear what people are saying about the examples?

4) BGP Extensions for PCE Discovery [Dhruv Dhody/Jie Dong] (10)
 https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp

Dhruv presenting.

[presentation]
Draft was presented in PCE in the past, also want input from IDR.
[discussion]

Ketan Talaulikar/Cisco: For the encodings you use ISIS style TLVs, but for OSPF
they are different. BGP-LS follows two byte OSPF style TLV encodings. Dhruv:
Will be checked. Ketan Talaulikar/Cisco: Another comment - would be good to
describe the use cases and scenarios. Dhruv: One of the reasons is that there
is a PCE document with requirements for discovery. We need to reference that
document and may add something from BGP-LS point of view to this document.
Ketan Talaulikar/Cisco: IGP based discovery covers IGP domain wide, now we have
scenarios that are inter-AS. Sue: Are you concerned about specific scenarios?
Ketan Talaulikar/Cisco: Yes, there are scenarios of redistribution IGP-BGP-IGP.
Sue: You should describe those scenarios on IDR mailing list.

New Work [14:20-15:30]

5) BGP Revised Data Store model [Susan Hares] (10)
https://tools.ietf.org/html/draft-mks-idr-bgp-yang-model/

Sue presenting.

[presentation & discussion]

This is a revised datastore version of the model based on OpenConfig. The OC
model is not going to be adopted in NETMOD. Two different models and two
different decisions, this is not good for deployment. We require two
interoperable implementations, it is not the case here, fundamental differences
in where operational state is stored in the tree. Sue/chair hat on: proposed
solution differences. There are different formats but the same equivalent
information. After discussions including routing ADs, the solution is to
publish OC model, it will not go STD track but informational. This draft does
exactly that. Lou mentioned that versioning precludes publishing of both
modules at the same time. We may use different names for different modules.
Chair hat on - it seemed right thing to give an opportunity for OC people to
reuse their work. I do not know how ADs will handle updates to OC modules. This
is an encouragement for putting modules on the Github. Rob Wilton/Cisco:
Namespace issue - it does not matter what namespace you use for OC drafts. They
are implemented in OC namespace, there is no version issue here. Sue: Repeating
- the OC module and NMDA module has to have different names. Rob Wilton: That
is not what people will be implementing, they will be using OC namespace. The
IETF name in the OC informational draft doesn't matter as no one will actually
implement that. A particular version in that particular OC name space. Mahesh:
The question is - you are referring to the original IETF draft for BGP and the
IETF namespace. That was written with IETF namespace. No-one implemented that.
If you want to publish it, we have to give the namespace. That namespace will
be IETF namespace. Rob Wilton: You can call it ietf-bgp-opencoinfig :-) Sue:
That was my suggestion. Lou: If they have different names you have no
versioning problem, they are not related. They are different modules. The other
question - the point was made that no-one should implement OC version. If
no-one is going to implement that, why are we publishing? Jeff Tantsura: There
are 7 implementations. Sue: It is current the IDR BGP model we are switching
off. . Lou: If you expect people to implement then publish. Lou: It means that
Rob Wilton¡¯s comment was not accurate. Rob Wilton: Have people implemented OC
module with OC namespace, or have implemented IETF draft? Lou: The reason it
does not compile within IETF context. If you bring other OC modules it
complies. Keyur Patel/Arrcus: To answer Rob Wilton¡¯s and Lou's questions,
there are implementations that are pure OC based. They compile, no issues. Sue:
The reason why I would like it be published - BGP selections inside that module
are wise. The choices made for BGP are wise. I want to ensure that we have a
copy for IPR purposes of those wise choices. Rob Wilton: In that case it would
be better to publish references to particular version of OC module that should
be implemented. That would be better than creating a third module in different
namespace. Jon Mitchell: I do not understand why not referencing the OC module
directly in the information draft, we should not publish something in IETF name
space. Sue: It seemed reasonable because people had contributions. I will take
this to the list. Lou: One modification to Rob Wilton¡¯s proposal - publish the
work as just data structures but not the modules. Publish that as informational
but not as a compliable module. That would avoid all reference problems. You
will not end up with a compliable module that no one is going to use. Keyur
Patel: It is important that we publish this, there are shipping implementations
that can be referred. Lou: Is that IETF namespace or OC namespace? Keyur: OC
namespace. Sue: We need to talk offline. Ruediger Volk: I am getting confused.
What I wonder - publishing stuff is fine, publishing stuff on stuff that has
been implemented is even better. Recently I have learned that vendors have
their own models and they are doing mapping and transformation of the modules.
I wonder whether the stuff that you are going to publish will cover the naming
and transformation. It would be good that the audience does not get confused
even more of that modules are available in the space. Sue: We will issue
adoption call. We need to move to revised datastore architecture. Does anyone
have problems with this approach? Himanshu Shah/Ciena: I have sent email on
some missing attributes (address families). That was one of the drafts that had
those attributes and after the merge it all got lost. Sue: I know what you are
talking about, I will address this. Sue: Any other concerns about adopting?
Sue: Once we settle on the revised datastore model, we will take other modules
depending on it. Once we adopt this, we will adopt the extensions.

6) BGP Link State extensions for IPv6 Segment Routing(SRv6) [Gaurav Dawra] (5)
https://tools.ietf.org/html/draft-dawra-idr-bgpls-srv6-ext/

Gaurav presenting.

[presentation]

[discussion]
Keyur Patel: It is a great draft, I have not read it. :-) You are carrying SRv6
information. What happens if my tunnel SAFI has IPv4 and IPv6 encapsulation
capabilities? Gourav: That is not specific to this Keyur: This is specific to
BGP. You may want to clarify this in the draft. Gourav: We can verify that.
Jeff Tantsura: The number of TLVs is defined in a similar way as MSD
capabilities. Ahmed Bashandy: It is better to put one piece than in separate
small pieces. Jeff Tantsura: You are signaling redundant information. Ahmed:
Not really. Jeff Tantsura: If you build both software and hardware I would
agree. In disaggregated world you will start confusing everybody. Gourav: It
may end up being more confusing that having one interface. Ahmed: We encode it
as a single element, while you are suggesting to have in different TLV
fragments. Mach Chen: There is another draft that defines similar extensions
that has different implementation details. We can discuss offline how to
approach. Ketan Talaulikar/Cisco: Jeff, you mentioned that information is
redundant, I didn't quite catch that Jeff Tantsura: It is not redundant, it is
defined in multiple places.

7) Segment Routing based Service Chaining [Gaurav Dawra] (10)
https://tools.ietf.org/html/draft-dawra-idr-bgp-sr-service-chaining/
https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining/

Gourav presenting.

[presentation]

[discussion]

Keyur: I have a question for chairs. There was a draft presented that was
intended for service chaining. I have a recollection that at that time service
chaining was not in charter for this WG. Sue: Let me talk to Alvaro. He is not
here until Tuesday. I will send a note to the list on the outcome of the
discussion. Gourav: We are defining BGP-LS extensions in this draft, not the
service chaining itself. Sue: Keyur, can you send a pointer to the draft you
mentioned? Keyur: Will do. Sue: This falls into the coordination between IDR
and SFC.

---

Sue: I have 1 WG adoption and 1 codepoint allocation. If you miss your
allocation and miss LC , do not be shy for sending us another message. Sue: End
of meeting.