Re: ISSU Charter paragraph

Hi Sarah,

>From: Banks, Sarah [mailto:[email protected]] >Sent: Tuesday, January 21, 2014 7:04 PM
>
>Hi Bruno,
>	Thanks for your input! I wanted to touch base on a point you raise
>below,
>however. In Service Software Upgrades imply that they¹re done in service;
>now, we all know that there aren¹t SP¹s or operators out there doing this
>in service, for a variety of reasons, but in adhering to the tenet of ³In
>Service², this would actually preclude Graceful Restart (GR); it would
>actually require Non Stop Routing (NSR) for supported routing protocols to
>be enabled. Indeed, it¹s our approach that the moment a routing neighbor
>flaps, you record the behavior, but you¹ve actually failed ISSU, because
>you interrupted the ³service² of ³in service². 

So it really depends on the definition and scope of "service" that you are considering.
For IP routers, the main service is forwarding IP packets, in the forwarding plane. So if they can be upgraded while the forwarding plane be kept running, I (and afaik routers vendors) call this ISSU.

e.g. among first hits on google

"The major elements supporting the functionality of the SSO and ISSU for Cisco IOS XE VPN 6vPE and 6PE features are the following:

[...]
    BGP Graceful Restart--The BGP Graceful Restart feature is responsible for negotiating graceful restart capabilities, exchanging forwarding preservation states, and coordinating advertisements after session restarts. MPLS VPNs interact with BGP to exchange VPN routing and forwarding (VRF) routes and labels."

http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ha/configuration/xe-3s/mp-6vpe-6pe-issu-sso.html


Now if IP forwarding is probably the main service of a core router, an edge router may provide additional services.
If you go that way, the first step may be to define what the service is.

>While we continue to find
>ways to state this without sounding like a conformance paragraph - because
>BMWG doesn¹t do conformance testing - it¹s certainly worth gathering
>input. :) Would you agree that NSR is a fundamental requirement for an
>ISSU operation?

AFAIK, no. But if you have an agreed upon definition of ISSU, I would be interested in reading it.

On a side note, we could also discuss the meaning of NSR, which probably mostly means that a routing session with a vanilla router stays up. But this does not mean that ISSU has no impact on the peer router (e.g. some implementation sends a BGP Route Refresh). Also AFAIK, NSR says nothing about other control plane services.(e.g. DHCP relay/server, IGMP request...)


Finally, my comment seems in synch with the proposed high level goal of characterizing the impact of ISSU on both the forwarding and control plane:

>>>In Service Software Upgrade (ISSU): Develop new methods and
>>> benchmarks to characterize the upgrade of network devices while
>>> in-service, considering both data and control plane operations and
>>> impacts.


Best regards,
Bruno

>Kind regards,
>Sarah
>
>On 1/21/14, 1:13 AM, "[email protected]"
><[email protected]> wrote:
>
>>>From: joel jaeggli >Sent: Monday, January 20, 2014 7:57 AM
>>>
>>>On 1/19/14, 7:51 PM, MORTON, ALFRED C (AL) wrote:
>>>> BMWG,
>>>>
>>>> As we continue to build our new charter step-by-step, here's the
>>>> first draft paragraph Sarah and I put together for your review:
>>>>
>>>> In Service Software Upgrade (ISSU): Develop new methods and
>>>> benchmarks to characterize the upgrade of network devices while
>>>> in-service, considering both data and control plane operations and
>>>> impacts. These devices are generally expected to maintain control
>>>> plane session integrity, including routing connections. Packet loss
>>>> should be measured and recovery behavior noted accordingly.
>>>
>>>Quantification of impact does seem like the key deliverable.
>>
>>+1
>>
>>Packet loss in the forwarding plane is the main impact. Multiple
>>forwarding planes may be involved: IPv4, IPv6, MPLS, Ethernet (including
>>MPLS VPNs)
>>Other impacts may be:
>>- control plane impact on neighbor. Ideally no impact, but some
>>implementations may delegate some work on the neighbors (e.g. for BGP:
>>Graceful Restart, Route Refresh))
>>- delayed rerouting (e.g. how long are routing messages delayed)
>>- missed control plane events (e.g. ARP, DHCP, IGMP...) especially on the
>>subscribed side
>>
>>Ideally, all impact should be identified as this may impact when and how
>>the maintenance/ISSU will be performed.
>>E.g. during the day or the night (typically depending on the forwarding
>>plane impact); the need for someone to be present/available/ready to go
>>on the peers promises (the more control plane impacts on the peer, the
>>more risks)...
>>
>>
>>
>>>> We'd like to have any comments on this proposal in the next 2 weeks.
>>>>
>>>> As a reminder, we have already reviewed the items below, and we have
>>>> at least one or more items to sort-out before we re-charter.
>>>>
>>>> regards, Sarah and Al
>>>>
>>>>
>>>> * Traffic Management: Develop the methods to characterize the
>>>> capacity of traffic management features in network devices, such as
>>>> classification, policing, shaping, and active queue management.
>>>> Existing terminology will be used where appropriate. Configured
>>>> operation will be verified as a part of the methodology. The goal is
>>>> a methodology to assess the maximum forwarding performance that a
>>>> network device can sustain without dropping or impairing packets, or
>>>> compromising the accuracy of multiple instances of traffic
>>>> management functions. This is the benchmark for comparison between
>>>> devices. Another goal is to devise methods that utilize flows with
>>>> congestion-aware transport as part of the traffic load and still
>>>> produce repeatable results in the isolated test environment.
>>>>
>>>> -=-=-=-=-=-=-=-=-=-
>>>>
>>>> IPv6 Neighbor Discovery-related benchmarking: Large address space in
>>>> IPv6 subnets presents several networking challenges, as described in
>>>> RFC 6583. Indexes to describe the performance of network devices,
>>>> such as the number of reachable devices on a sub-network, are useful
>>>> benchmarks to the operations community. The working group will
>>>> develop the necessary terminology and methodologies to measure such
>>>> benchmarks. _______________________________________________ bmwg
>>>> mailing list [email protected]
>>>> https://www.ietf.org/mailman/listinfo/bmwg
>>>>
>>>
>>
>>
>>__________________________________________________________________________
>>_______________________________________________
>>
>>Ce message et ses pieces jointes peuvent contenir des informations
>>confidentielles ou privilegiees et ne doivent donc
>>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce message par erreur, veuillez le signaler
>>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>electroniques etant susceptibles d'alteration,
>>Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou falsifie. Merci.
>>
>>This message and its attachments may contain confidential or privileged
>>information that may be protected by law;
>>they should not be distributed, used or copied without authorisation.
>>If you have received this email in error, please notify the sender and
>>delete this message and its attachments.
>>As emails may be altered, Orange is not liable for messages that have
>>been modified, changed or falsified.
>>Thank you.
>>
>>_______________________________________________
>>bmwg mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/bmwg


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.