Re: ISSU Charter paragraph

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². 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?

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