Source
Packet Routing In Networking (SPRING) @ ietf92:
THURSDAY,
March 26, 2015 1740-1840
== Chairs Update:
o New co-chair: welcome Bruno!
o Charter, where are we making
progress:
- Chairs have reviewed the zoo of drafts, with
a view of how we make progress towards delivering the charter.
- There are a mix of drafts that are
individual and WG documents which satisfy the WG charter requirements, but
there are also drafts that might not do this - this is not a reflection of the
work done, but rather an aim to progress SPRING with the minimum number of
documents.
- Use cases are generally in-line, although
some requirements to finish off IPR calls, and some edits that are required. Stefano
has Alvaro's comments, and aims to address them in the near future.
o Draft status:
- An abstract architecture has been done for
data-planes - draft-ietf-spring-segment-routing
- Essentially MPLS dataplane
does not need changes - and hence N/A to these charter items.
- The requirements are generally implicit in
the architecture documents.
- Control-plane extensions: which of the
extensions should we track as WG documents - aim not to create new work items,
but point to work in the relevant working-groups.
- OAM mechanisms to support SPRING for
MPLS+IPv6 - MPLS has some documents, but IPv6 has a
lack of items.
- Inter-working items are generally on-track.
- For IPv6 - there is a requirement to
cross-last-call in 6man to allow review and demonstrate use-cases for SPRING in
IPv6 before adoption of the SPRING IPv6 routing header.
- Please contribute over in 6man if there is
interest in IPv6 SPRING.
o Working group next steps:
- Update milestones.
- Move the architecture and use-case documents
forward.
== Stefano Previdi - Working Group Drafts
Update:
o Existing Working Group Items:
- Updated architecture draft: ready to go, all
comments have been addressed.
- IPv6 use-cases: both the SRH and SRH
security headers are being discussed in 6man.
- MPLS data-plane draft: no changes, but may
need some clean up. Aim to last call relatively soon.
- Problem statement: comments from Alvaro to
be addressed, which are in progress.
- Resiliency use cases: no changes on this
draft.
o Potential new work items to
address:
- SR use case draft (draft-filsfils-spring-segment-routing-use-case):
there is some text duplication across this document and the problem statement,
but there are some elements that are potentially of use going forward (e.g.,
how to use SR for TE).
- Aim to update and refresh/re-name this
draft.
- Re-spin will be SR-TE motivated.
- SR-LDP interop:
- Multiple implementations already - stable
and ready for WG adoption.
- BGP drafts:
- Both describing MSDC and Centralised EPE -- ready for adoption?
- Segment Routing TI-LFA:
- Should this be moved to rtgwg?
- John Scudder: Discussion with Jeff T
(chair of rtgwg), and the guidance was that this
should go to rtgwg.
- Conclusion: BGP-SR, LDP-interop -- would
like these to be adopted by the working group.
- *ACTION* Chairs to call
for adoption on the SPRING mailing list.
== Bidirectional Forwarding Detection (BFD)
Directed Return Path
draft-mirsky-mpls-bfd-directed-03
Greg Mirsky 5 minutes
o Added author and reviewed by Loa A.
o Added a new Return Code:
- Introduced a new error code to indicate that
there is no return path available - used by the egress LSR.
o Extension used to specify the
reverse path between two devices - example shown in slides.
o Also presented in the MPLS WG -
asked for adoption, hoped to be adopted by IETF 93 in Prague.
o No comments/questions.
== YANG Data Model for Segment Routing (I) 10 minutes
draft-litkowski-spring-sr-yang-00
Stéphane Litkowski
o Model being proposed for both cfg and operational state for SR.
o Expecting discussion today - cfg is part of routing protocols in most implementations,
querying whether this is the right place in the cfg
tree.
- If we have a network which is composed of
multiple protocols, then some parameters are critical to be global (e.g., SRGB
should be shared across protocols).
- Hence proposing the core routing YANG model
is directly extended. Remaining queries as to whether the SRGB is a
chassis-wide configuration, or whether it is per routing-instance.
- Uma (Ericsson): Mapping entries should be
named such that they can be linked from an IGP instance.
- Stephane: Do you expect to have different
mapping entries per IGP?
- Uma: Question is about associating the
mapping to the IGP - how do we link this to a particular instance?
- Stephane: Discuss off-line, not sure on what
is being proposed.
- Hannes: Mapping server cfg
could be implemented using routing policy rather than using this static
mapping.
- Stephane: Not all implementations are
considering LDP as a routing protocol...
- Hannes: But the mapping is from to IGP-LDP -
and should be policy.
- Stephane: We can take the discussion
offline, but can see an opportunity for the policy.
- Robin (Huawei): Is the mapping server a
node?
- Stephane: The mapping server is definitely a
node.
- Acee: If the item is not the mapping server
- then we omit this config. This is used where a node
is a SR node AND a mapping server.
o Interface configuration:
- How should we handle the AdjSID?
Want to specify both protected/unprotected, and then a bundled set of
interfaces (with the same AdjSID).
- Configuration of the Prefix-SID under
interfaces too: allows leaking of protection into the model.
o Query regarding the S-flag:
- Proposing to use the S-flag with a Group-ID.
o Protocol extensions:
- Proposing an augmentation of OSPF and IS-IS
to extend.
o Operational state and notifications
being added.
o Next steps:
- SR YANG model is coming from the people
working on IS-IS and OSPF YANG models.
- Time to work on this - since implementations
are just shipping now. Would like common config.
- Issues to resolve:
- SRGB scope.
- Transport-plane scope.
- Protocol extensions.
- Would like adoption.
- Shraddha (Juniper): You have the interface config in the interface model too?
- Stephane: It is specified under the
protocols.
- Shraddha: Configuration should be under each
protocol - it is unusual to have this within the protocol.
- Stephane: Could consider SR as a routing
protocol - hence makes this more logical.
- Sri (Ericsson): Are you planning to model
h/w capabilities?
- Stephane: Maybe. It would be interesting for
EL.
- Pushpasis: A container generally, and
potentially configuration underneath the protocol.
- Acee: We'll make a container that can be
augmented by a particular implementation.
- Uma: Cannot put everything in SR, some
should be under the IGP config.
- Stephane: We should discuss.
== YANG Data model for Segment Routing (II) 10 minutes
Fangwei
Hu
o Alternative model for SR - cfg hierarchy as per slides.
o Also defined notifications.
o Received some comments - e.g.,
adding the mapping server.
o Offline discussion with some
authors from other models:
- Removed TE related nodes and forwarding label
related elements.
- Augments from other models (e.g., MPLS-TE).
o John S (with chair hat): Comment
for the authors of both drafts. Does not seem likely that the WG will adopt two
drafts -- encouraged to work to improve one draft and move it forward together.
== Entropy Label for SR-MPLS 5 minutes
draft-ietf-mpls-spring-entropy-label-00
Sriganesh
Kini
o Just become a working-group draft
in MPLS WG - a few weeks ago.
o Background: how do we get
load-balancing.
o Changes since ietf91:
- Changed to an SR-TE Node/Adj-SID
based use-case.
- Improved the readability of the algorithm.
o Use case with both parallel links
and ECMPs - requirement for hashing.
- P1 has a RLD=4. In use case, EL is too deep
for P1 to read. The draft makes recommendations.
- Insert multiple ELI/ELs - to allow hashing.
o How do we specify RLD - should this
be interface specific?
- Significant complexity if it is - benefits
appear to be minimal, no strong use-case to do this.
- Second discussion w.r.t OAM - requirements
are still being discussed. Solution is not expected to introduce new problems.
o Questions/comments.
- Jeff T: Do we need per interface? If so,
please let us know as we are thinking about it for ELC.
- Sri: It is not that simple to work out what
we do if we do per-interface.
- John S: I heard "not that simple",
so a compelling use-case would be required?
- Sri: Yes
== Multi-Topology (MT) Segment in Segment Routing 5 minutes
draft-li-spring-multi-topology-segment-00
Eric Wu
o Use case for MRT-FRR - MT-Red &
MT-Blue used for alternatives.
o No space in the IP hdr to do this, but define an MRT-SID to use.
o MT-SID defined:
- ingress - PUSHes MRT-SID-Red or MT-SID-Blue to steer the packet.
- transit router
CONTINUEs
- egress router -
NEXT
o Control plane mechanism:
- IGP extension for the MT-SID, which is
unique within the IGP domain.
- Recommended that this is allocated centrally
- details are TBD.
o Looking for interested parties to
discuss.
o Kireeti Kompella (Juniper): I have
a naive question, if you do MT-ISIS, why would you need MT-SID?
o Eric: Trying to solve the MRT
problem in a SR network.
o Kireeti: Aiming to solve MRT rather
than MT.
o Robin (Huawei): IGP-MT has no
header in existing network, and DSCP is used...so we want to use MPLS.
o Kireeti: Didn't get that, will read
the draft.
o Hannes: The SR design team put
sufficient provisions in the IGP extensions for additional protocols, indexes
and label blocks should be extended with a code point for MRT, and then re-use
the existing label block mechanism that is already defined. You're defining
something that requires a double-lookup which might be quite expensive.
o Stefano: I agree with Hannes. To Kireeti's point, it's already defined in IS-IS. We might
need one TLV.
o Kireeti: After a side-discussion -
you really want to MRT, you can do this calculation at the head-end using
existing SIDs - if you do this either at the head-end or at a magical
controller you can build a stack at the head-end.
o Chris Bowers (JNPR): The idea is
not to use the label stack for MRT. We want a Node-SID that has an MRT-Blue or
Red algorithm.
- John S: That's a wrap - see you next time,
we have a lot to discuss on the list!