Re: ISSU Charter paragraph

Bruno, while some definition of  ISSU are "quite vague /  open”  for this
specific vendor you are referring,  take a look at the following page
where it’s ISSU definition and basic required architecture are defined ..

I agree with you point and to me is  technically valid, but the main idea
of real ISSU is not rely on another device  to piggy back the process /
failure  I.E GR procedures. What would happens for example in the case of
the L3 VPN provider with thousands of unmanaged Ces that do not support GR
? 

Check the following  documentation from the same vendor and yes, you will
find quite a few contradicting information and definitions floating around
.. :) This is one of the main golas / objectives of the document we are
proposing , which is basically :  standarize  the definition describe the
procedure and how to qualify , benchmark the duration of the outage /
overall process impact …

http://www.cisco.com/en/US/products/ps7149/products_ios_protocol_group_home
.html

And more specifically the following PDF..

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6550/prod_pres
entation0900aecd80456cb8.pdf



Rgds 

Fer








On 1/22/14, 4:48 AM, "[email protected]"
<[email protected]> wrote:

>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-6
>vpe-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.
>
>_______________________________________________
>bmwg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg