Minutes for I2RS at interim-2015-i2rs-1

Meeting Minutes Interface to the Routing System (i2rs) WG
Title Minutes for I2RS at interim-2015-i2rs-1
State Active
Other versions plain text
Last updated 2015-01-08

Meeting Minutes

I2RS interim 2014-01-08

Jeff Haas
Susan Hares
Chodorek ?
Dean Bogdanovic
Ignas Bagdonas
Dhruv Doty
Amit Dass
Don Fedyk
Joe Clark
Gonzalo Salgueiro
Sriganesh Kini
Jürgen Schönwälder
Jie Dong
Alexander Clemm
Alia Atlas


Document status and design teams

Need to review security directorate feedback on architecture.
Need to get the documents to the

Joe will be giving us an update on the traceability document.
Sue will provide rib-info model update.  No update ready for today.

Problem statement: received directorate feedbacks - that has been integrated
and will be sent out shortly.

Architecture draft: small comments from various people, integrated, but need to
address security directorate comments. Charter needs to be revised after
problem statements and architecture drafts.

Security issues:
Questions [slides]

Ignas: On Q1 next steps - are you talking about general protocol requirements
or just security review comments? Sue: These are working group decisions.  Need
to look at netconf or restconf with features added to either. Ignas: The way I
read the security directorate comments is that they are concerned about
slightly different things. Not netconf, etc. Separate signaling protocol, they
are concerned about the transport issues. Sue: You think they may be asking
about the content of the protocol? Ignas: Not that missed something. Two
orthogonal aspects. Restconf can run over TCP and others. Security directorate
is asking about transport security. Jeff: we are providing requirements for
what we need; see restconf/netconf transport requirements. Ignas: They are
asking about authentication requirements. Jeff: Think this is covered still in
the protocols in question. Sue: Can ask the security reviewer what they meant.

Q2 Validation credential of second ID.
Sue: Is everyone comfortable with secondary ID as opaque string?
Joe Clark: Updated traceability draft to cover this as “actor ID”.  Agent may
validate that a client can use a given opaque string, but not part of the
authentication protocol. Alia: Secondary identifier just for troubleshooting. 
If agent is acting as broker, there was concern we wouldn’t have enough
information for that troubleshooting. Sriganesh: Alia, to simplify
troubleshooting or enable? Still could do this based on agent IDs. Alia:
Simplify it. Sriganesh: Need more explanation of what we mean by opaque?
Operating on it at the agent? Treating each client separately. Alia: Opaque in
terms of no understanding of what’s inside.  No decisions. Sriganesh: As long
as we clarify that it’s no decision making.

Q3.1: Security and asynchronous nature of i2rs protocol
Alia: Last write wins - based on priorities not tied. Labels for transactions
are not the default. Jeff: Feedback from NYC interim was that there is not a
clear mechanism for priorities at this time.  Could be done with metadata. 
However, protocols would not use these for adjudicating whether one bit of
config wins or not.  Work required in protocols. Alia: This has been in
architecture for a long time. Jeff: Just highlighting things that may hinder

Checkpoint or transaction labels.
Sue: It is unclear that the security directorate may not have read the priority
stuff.  Write responses - unclear about what the group thinks about labels?
Jeff: NYC netmod interim indicated that transctions and validation may slow us
down. We may need to avoid these to be fast? Dean: Restconf transactions are
atomic. You can have multiple transactions within same session. Sue: Does that
gives us the labeling that Alia wants? Dean: I think it does, but need to
check. Alia: It is like a message-id. Need to get into the particular details
about how a protocol can do it? Jeff: I don’t think that async transactions
existing yet. Alia: Alex, does pub-sub cover this? Alex: Do not think it is
directly applicable. Configuration vs. subscription. Alia: When you send your
write - subscribe to that response? Other clients may want to get those
responses. Alex: Be able to refer to a particular subscription? Alia: Client
does a write, subscribe to a notification for a particular response. Second
client may want to get those responses as well. Alex: Need to discuss this
requirement. If we want to apply this to configuration changes, that is another
mechanism. We were going after operational data. Jeff: Could you make sure to
point out in the mailing list where the requirement is for async writes for
config state? I think the subscription requirements are clear. Alia: Ok. Sue: I
have not heard of any restconf/netconf protocol checkpoints Jeff: Do not think
it is spelled out. Would slow us down. Alia: No, checkpoints are not in arch.
Not even transactions. Just message-ids. Dean: In restconf, uses HTTP methods -
states actions we’re doing. POST is atomic. Multi-message transaction? Alia:
No, only single message in transaction. Dean: In restconf, can only be read or
write, not both.

Jeff: There is no indication that a discontinuity has happened. We may need
this to help with restart of agent. Alia: Just need to get this into the